implicit *LWS ?

[Alexandre Snarskii]

On Wed, Oct 06, 2010 at 01:52:52PM +0100, Valery Kholodkov wrote:
> 
> Это фича. В Вашем запросе указан HTTP/1.0, следовательно смотреть 
> нужно в rfc 1945.
> 
> Относительно LWS rfc 1945 говорит (пункт 2.2):
> 
> However, folding of header lines is not expected by some
>    applications, and should not be generated by HTTP/1.0 applications.
> 
> Таким образом Ваш запрос не следует рекомендациям.

should not, вообще говоря, не запрещает использовать folding
(иначе здесь был бы must not), а просто "не рекомендует". 
А пункт 2.1 того же RFC1945 содержит примерно то же, что и в RFC2616,

 implied *LWS

       Except where noted otherwise, linear whitespace (LWS) can be
       included between any two adjacent words (token or
       quoted-string), and between adjacent tokens and delimiters
       (tspecials), without changing the interpretation of a field. 

То есть - LWS может использоваться, хотя это использование и не 
рекомендуется. 

> Если бы в Вашем запросе был указан HTTP/1.1, то это был бы баг.

Ok, повторяем тот же эксперимент заменяя в запросе HTTP/1.0 на HTTP/1.1, 
оставляя LWS на месте.  

И при proxy_pass и при fastcgi_pass получаем ровно то же поведение: 

T 192.168.13.202:47692 -> <...>:80 [AP]
GET /picture.jpg HTTP/1.0.
Host: ....
Connection: close.
Accept: text/plain, text/html,.
.

accept срезан на CRLF'е. Ok, этот запрос уже преобразован из HTTP/1.1
в HTTP/1.0, но если такое "обрезание" - это попытка следовать приведенной
Вами рекомендации - nginx, jimho, должен был заменить LWS на SP (как это 
делает, например, haproxy), ибо согласно и rfc1945 и 2616, LWS has the 
same semantics as SP (цитируется по 2616), а 2616 и вовсе добавляет, что

A recipient MAY replace any linear white space with a single SP before 
interpreting the field value or forwarding the message downstream.


> ----- Alexandre Snarskii <snar at snar.spb.ru> wrote:
> > 
> > Hi!
> > 
> > Дано: nginx/0.8.52 (собранный из FreeBSD ports без добавок), вот такой 
> > вот запрос (обратите внимание на linear white space внутри поля Accept): 
> > 
> > GET /picture.jpg HTTP/1.0
> > Accept: text/plain, text/html,
> >     */*
> > Host: .....
> > 
> > Пытаемся послать его через nginx с минимальным конфигом 
> > (location /picture.jpg { proxy_pass http://....; proxy_set_header Host ....; })
> > в ngrep'е видим следующее: 
> > 
> > T 192.168.13.202:52556 -> <....>:80 [AP]
> > GET /picture.jpg HTTP/1.0.
> > Host: ....
> > Connection: close.
> > Accept: text/plain, text/html,.
> > .
> > 
> > то есть nginx при проксировании обрезал весь контент поля начиная с CRLF.
> > 
> > То же самое происходит если пытаться передавать запрос на fastcgi backend,
> > в параметре HTTP_ACCEPT я вижу только text/plain, text/html, но не */*.
> > С другими хидерами происходит то же самое - как только встречается LWS - 
> > поле "обрезается", что для proxy_pass, что для fastcgi_pass. 
> > 
> > Вопрос: это бага или фича ? Если фича - обойти как-нибудь можно ? 
> > 
> > PS: по RFC судя - бага, RFC2616 в разделе 2.1 говорит о impled *LWS: 
> > 
> > implied *LWS
> > 
> >     The grammar described by this specification is word-based. Except 
> >   where noted otherwise, linear white space (LWS) can be included between 
> >   any two adjacent words (token or quoted-string), and between adjacent 
> >   words and separators, without changing the interpretation of a field. 
> 
> -- 
> Regards,
> Valery Kholodkov
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is.