Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ошибка в mod_proxy OR mod_upstream ?
Hello!
On Tue, May 19, 2009 at 07:35:10PM +0400, Илья Винокуров wrote:
>
> Здравствуйте, Игорь!
> Обнаружил то ли багу, то ли фичу:
>
>
> Использую:
> upstream UP1 {
> server ip.ip.ip.ip;
> }
>
> location /UP/ {
> internal;
> ssi_types text/plain;
> # ssi on;
> proxy_pass http://UP/cgi-bin/script/;
> proxy_read_timeout 5;
> proxy_send_timeout 5;
> proxy_connect_timeout 5;
> }
>
> <!--# include virtual="/UP/cgi-bin/script?${args}" wait="yes" -->
>
>
> А апстримный сервер находится в разработке и выдает такую хню:
>
> HTTP/1.1 200 OK
> Content-Length: 43
>
> дата 43 байта
>
> HTTP/1.0 500
> Connection: close
> Content-Type: text/html
>
> <HTML><BODY>Internal Server Error</BODY></HTML>
>
>
> По моему разумению mod_proxy должен по первому заголовку выкусить 43 байта
> данных и вернуть в SSI.
> Т.е. строки
> HTTP/1.0 500
> Connection: close
> Content-Type: text/html
>
> <HTML><BODY>Internal Server Error</BODY></HTML>
>
> Должны бы потеряться в мироздании. Так делают браузеры.
>
> Но в случае с nginx весь ответ сервера передаетсся в SSI.
> Для отладки удобно, а вот с точки зрения логики не понятно.
С точки зрения логики - в HTTP/1.0 конец ответа в любом случае
сигнализируется закрытием соединения, и именно его nginx в
настоящий момент использует.
Более того, в RFC1945 сказано:
7.2.2 Length
...
Note: Some older servers supply an invalid Content-Length when
sending a document that contains server-side includes dynamically
inserted into the data stream. It must be emphasized that this
will not be tolerated by future versions of HTTP. Unless the
client knows that it is receiving a response from a compliant
server, it should not depend on the Content-Length value being
correct.
Я никоим образом не хочу сказать что этого абзаца надо
придерживаться в современных условиях, но по факту nginx именно так
сейчас делает. И в частности вам это помогло поймать ошибку в
бекенде.
А если бы это был HTTP/1.1 с пайплайнингом и постоянными
соединениями - вы бы посидели, пытаясь понять почему некоторые
клиенты иногда получают 500 ошибки неизвестно откуда на случайные
запросы. :)
Maxim Dounin
|
