Ошибка в mod_proxy OR mod_upstream ?

Wed May 20 01:07:29 MSD 2009

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