Это фича. В Вашем запросе указан 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.

Таким образом Ваш запрос не следует рекомендациям.

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

----- Alexandre Snarskii <snar@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@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru