On Tue, Dec 14, 2010 at 12:33:02PM -0500, Denis wrote:

> [quote]
> This should be added to default server, as error 400 is generated
> before any server_name matching occurs.
> [/quote]
>
> Yep, I added it to the default server. At least, it's listening as
> [code]
> listen 80 default;
> [/code]
>
> [quote]
> Note that you may also bump client_header_buffer_size /
> large_client_header_buffers if you want cookies in question to be
> actually accepted and processed (this should be done in default
> server, too, or at http level).
> [/quote]
> That's exactly what I'm bumping. Sorry, I should have made it more clear
> in my first post. I don't want to make my large_client_header_buffer 1
> megabyte and I need some kind of way to fall back gracefully when a
> client appears with 1Mbyte cookie. Like show him a page saying "your
> cookie is too large, please delete it" or delete it in javascript.
> But the problem is, I either get that hardcoded simple page or get http
> response with no response body at all.
> [code]
> $ curl http://foobar.com/ -b hugecookies.jar
> HTTP/1.1 400 Bad Request
> Server: nginx
> Date: Tue, 14 Dec 2010 17:29:07 GMT
> Content-Type: text/html; charset=EUC-JP
> Content-Length: 237
> Connection: close
>
> curl: (55) Send failure: Connection reset by peer
> $
> [/code]

The attached patch allows HTTP lingering close for 400 responses.
However, it will not be included in next releases: I'm going to
introduce a special code, say 490, for long HTTP header lines as
it's already done for SSL errors (495, 496, and 497). Then you can
set expliclty

error_page 490 =200 /large_cookie.html;


--
Igor Sysoev
http://sysoev.ru/en/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx