Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: implicit *LWS ?
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@xxxxxxxxxxx> 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@xxxxxxxxx
> http://nginx.org/mailman/listinfo/nginx-ru
--
In theory, there is no difference between theory and practice.
But, in practice, there is.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|