[AOLSERVER] Server behaviour with large cookies

[David Osborne]

Hi,

Can I check if the following is an intended behaviour?

We run Aolserver 4.5.1 on Debian Squeeze.

The behaviour we are seeing is, when a large cookie is sent in a request, the nsd daemon doesn't seem to reply at all.
(This also occurs with a large number of smaller cookies. ~50)

I constructed a test case by creating a cookie file containing 1 cookie (as attached) which is very long (probably illegally long) and used wget as follows:

 wget --server-response --load-cookies cookies_test_single2.txt http://www.domain.co.uk:8001/tcl/search.tcl?search=test

Then wget reports "HTTP request sent, awaiting response... No data received." and retries.
If I remove a couple of characters from the cookie, it will work fine.
(If anyone wanted to try it then obviously the domain in the cookie file would need to be changed to match yours.)

This first manifested itself with the nsd daemon running behind nginx. nginx would return a 502 with the error "upstream prematurely closed connection while reading response header from upstream". We then made the request directly to the nsd daemon's port and got no response at all.

So seems like I'm hitting an upper limit on cookie size which is fine.. but should we not get a error code back from the nsd daemon if that was the case, or is this working as designed?

If not working as designed, could this be a config problem on the server side?

Thanks in advance for any help.

Regards,
--
David Osborne
Qcode Ltd

[Jeff Rogers]

The default maximum length for a single line in the header is 4096
bytes, which your cookie will end up slightly longer than. An error
message should be logged in the server log, something line "max line
exceeded". It looks like the code just closes the socket when that
happens, tho I have a recollection of someone recently adding in patches
to make that cleaner and return an http error, but I'm not certain of that.

You can increase the max line length in the server config, in the driver
config section:

ns_section ns/server/YOUR_SERVER/module/nssock
ns_param maxline 8192

-J

> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> aolserver-talk mailing list
> aolserv...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/aolserver-talk


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
aolserver-talk mailing list
aolserv...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

[David Osborne]

Thanks for the info Jeff,
(apologies for the very delayed reaction!)..

Are these the commits you are referring to? (the non-nspostgres ones)

http://sourceforge.net/mailarchive/forum.php?forum_name=aolserver-commits&max_rows=25&style=ultimate&viewmonth=201107&viewday=9

Log Message:
- move the handling of "Entity too large" to the connection threads
- make sure to process the whole request from the client, even when the entity is too large
- change spelling of error stub to Ns_ConnReturnEntityTooLarge
- removed superflous newline in SockState

aolserver-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

--
David Osborne
Qcode Ltd

Tel: +44 (0)1312080151