Re: не работае т error_page 503 /503.html;

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Fri, Mar 20, 2009 at 03:09:30PM +0300, Igor Sysoev wrote:

> On Fri, Mar 20, 2009 at 01:38:32PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Fri, Mar 20, 2009 at 12:42:47AM +0200, Андрей Василишин wrote:
> > 
> > > Maxim Dounin пишет:
> > >> Hello!
> > >>
> > >> On Thu, Mar 19, 2009 at 04:40:39PM +0200, Андрей Василишин wrote:
> > >>
> > >>   
> > >>>> Как сделать так, чтобы при превышении limit_conn one  1; клиенту   
> > >>>> отдавалась /503.html, сейчас я так понял отдается 404 (Firefox не   
> > >>>> может найти файл)?
> > >>>>       
> > >>> Игорь, все-таки можно что-нибудь придумать или нет?
> > >>>     
> > >>
> > >> Пропробуйте 
> > >>
> > >>     location /503.html {
> > >>         add_header Content-Disposition "";
> > >>         ...
> > >>     }
> > >>
> > >> Это должно убрать из ответа заголовок Content-Disposition, который  
> > >> прилетает из скрипта отдающего X-Accel-Redirect, и судя по всему 
> > >> вызывает подобную реакцию FireFox'а.
> > >>
> > >> Maxim Dounin
> > >>   
> > > *syntax: *add_header */название значение/*
> > > *default: *нет
> > > *context: *http, server, location
> > >
> > > Директива добавляет строку в заголовке ответа при условии, что код  
> > > ответа равен 200, 204, 301, 302 или 304. В значении можно использовать  
> > > переменные.
> > >
> > >
> > > Тут ответ ведь 503
> > 
> > Да, я ошибся.  Кроме того, значение Content-Disposition 
> > вышеуказанная конструкция не очистит даже если сработает - 
> > add_header умеет чистить только Cache-Control и Last-Modified.
> > 
> > Workaround - попробовать возвращать Content-Disposition в другом 
> > заголовке, и добавлять через add_header если всё хорошо.  Как-то 
> > так:
> > 
> >     location /files/ {
> >         internal;
> >         add_header Content-Disposition $upstream_http_x_content_disposition;
> >         ...
> >     }
> > 
> > Но вообще наверное надо с этим что-то сделать кардинально.
> 
> Я думаю, нужно чистить Content-Disposition прямо в
> ngx_http_special_response_handler()

Вероятно.  Я даже почти уверен что это ничего не сломает.

Не совсем понятно что делать с другими заголовками в подобной 
ситуации.  В частности, из upstream'а сейчас могут прилететь при 
X-Accel-Redirect:

Content-Type
Set-Cookie
Content-Disposition
Cache-Control
Expires
Accept-Ranges

Из них сейчас чистится/переставляются Content-Type и 
Accept-Ranges.  Помимо Content-Disposition остаются ещё 
Set-Cookie, Cache-Control, Expires.  И что-то мне подсказывает что 
как минимум с последними двумя можно получить неприятностей.

Maxim Dounin