[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnu: Add erlang.
From: |
Nala Ginrut |
Subject: |
Re: [PATCH] gnu: Add erlang. |
Date: |
Mon, 04 Jan 2016 20:13:25 +0800 |
Someone had reported the similar problem to Artanis:
https://github.com/NalaGinrut/artanis/issues/44
It's because some client (firefox, in this case) emits wrong header. But
nowadays many clients seems break RFC. Maybe make the parsing rule
little looser is better.
And maybe add a warning? But seems useless to change anything.
So I agree with you to change our http parser.
Best regards.
On Mon, 2016-01-04 at 12:44 +0100, Andy Wingo wrote:
> On Mon 04 Jan 2016 06:20, Steve Sprang <address@hidden> writes:
>
> > From http://www.erlang.org/download/otp_src_18.2.1.tar.gz...
> > ERROR: Bad qstring header component: kMSMAn68110840
>
> This means the server is emitting bad HTTP. If I connect with:
>
> GET /download/otp_src_18.2.1.tar.gz HTTP/1.1
> Host: www.erlang.org
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/601.1 (KHTML, like
> Gecko) Version/8.0 Safari/601.1 Epiphany/3.16.3
> Accept-Encoding: gzip, deflate
> Accept-Language: en
> Connection: Keep-Alive
>
> The server responds with:
>
> HTTP/1.1 200 OK
> Server: inets/5.7.1
> Date: Mon, 04 Jan 2016 11:32:30 GMT
> Content-Type: text/plain; charset=utf-8
> Etag: kMSMAn68110840
> Content-Length: 68110840
> Last-Modified: Fri, 18 Dec 2015 11:00:38 GMT
> Connection:close
>
> ...
>
> The Etag value is invalid:
>
> https://tools.ietf.org/html/rfc7232#section-2.3
>
> We could relax Guile's etag parser to assume that an etag not starting
> with either W/ or " is a strong etag without quotes. To do that you
> would patch guile's http.scm to say:
>
> (define (parse-entity-tag val)
> (cond
> ((string-prefix? "W/" val) (cons (parse-qstring val 2) #f))
> ((string-prefix? "\"" val) (cons (parse-qstring val) #t))
> (else (cons val #t))))
>
> Considering that this error has come up a few times and that the less
> strict parser doesn't change the Guile programming interface or endanger
> the web in any significant way, I think changing Guile's HTTP parser
> would be OK.
>
> Thoughts?
>
> Andy
>