guile-devel
[Top][All Lists]
Advanced

[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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]