Although HTTP protocol doesn't have a limit on the cookie size, which is in turn a part of the request/response headers, Apache does impose a limit to protect the webserver from denial of service attaches.
Apache controls this using the "LimitRequestFieldSize" directive which defaults to 8192 byte as a max for a header field.
If larger cookies are needed, we need to bump up this value to a bigger number.
eg:
LimitRequestFieldSize 18192
in order to test this, i set up a simple webserver config with the below config:
RequestHeader unset If-Modified-Since
RequestHeader unset If-None-Match
LimitRequestFieldSize 18192
Header set Set-Cookie "apachenode=node1; path=/;"
Header add Set-Cookie "env=test; path=/;"
Header add Set-Cookie "TimeS=NONE; path=/;"
The LimitRequestFieldSize only works on Requests not on the response, thus apache can set-Cookies with large values with no problems, its the job of the browser to validate this.
To be able to test this from Firefox, I used the Cookie Manager plugin https://addons.mozilla.org/en-US/firefox/addon/cookies-manager-plus/ to set a large cookie that is 24k in size with a random string generated from the site: http://textmechanic.com/text-tools/randomization-tools/random-string-generator/
I managed to prove the compiled limit in Centos 7 is indeed 8192 and expanded that to ~18k as seen above and it worked.
When apache fails to accept the request it responses with an http 400 error as below:
Apache controls this using the "LimitRequestFieldSize" directive which defaults to 8192 byte as a max for a header field.
If larger cookies are needed, we need to bump up this value to a bigger number.
eg:
LimitRequestFieldSize 18192
in order to test this, i set up a simple webserver config with the below config:
RequestHeader unset If-Modified-Since
RequestHeader unset If-None-Match
LimitRequestFieldSize 18192
Header set Set-Cookie "apachenode=node1; path=/;"
Header add Set-Cookie "env=test; path=/;"
Header add Set-Cookie "TimeS=NONE; path=/;"
The LimitRequestFieldSize only works on Requests not on the response, thus apache can set-Cookies with large values with no problems, its the job of the browser to validate this.
To be able to test this from Firefox, I used the Cookie Manager plugin https://addons.mozilla.org/en-US/firefox/addon/cookies-manager-plus/ to set a large cookie that is 24k in size with a random string generated from the site: http://textmechanic.com/text-tools/randomization-tools/random-string-generator/
I managed to prove the compiled limit in Centos 7 is indeed 8192 and expanded that to ~18k as seen above and it worked.
When apache fails to accept the request it responses with an http 400 error as below:
I tried to do the same test with commandline curl but seems curl truncates the large cookie when using the -b option and passing a file as below:
[root@feanor conf]# curl -b ./cookies.txt http://localhost/new.html
this is a new page :)
[root@feanor conf]# ls -ltrh ./cookies.txt
-rw-r--r-- 1 root root 25K Sep 15 12:28 ./cookies.txt
[root@feanor conf]#
this is a new page :)
[root@feanor conf]# ls -ltrh ./cookies.txt
-rw-r--r-- 1 root root 25K Sep 15 12:28 ./cookies.txt
[root@feanor conf]#
Although the cookie file contains a single cookie that is 24k in size, curl seems to have truncated it and the request went in.
lowering the LimitRequestFieldSize to something like 4600 managed to have curl reproduce the same behaviors as the browsers:
[root@feanor conf]# curl -b ./cookies.txt http://localhost/new.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Size of a request header field exceeds server limit.<br />
<pre>
</pre>
</p>
</body></html>
[root@feanor conf]#
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Size of a request header field exceeds server limit.<br />
<pre>
</pre>
</p>
</body></html>
[root@feanor conf]#
Thus, curl could be tricking you if you are debugging an issue like this from the command line.
Also one more note about large Cookie sizes, if haproxy is used in the setup, eg: as a balancer in front of Apache or for SSL offloading, it could be needed to increase the tune.bufsize so that it can accept larger requests and larger Cookie sizes.
Haproxy checks the size as (tune.bufsize - tune.maxrewrite) where Maxrewrite is adjusted to half buffersize if that is larger than 1024.
Check the haproxy config at: http://www.haproxy.org/download/1.5/doc/configuration.txt.
Given the above info, tune.bufsize should be set to be double the Apache LimitRequestFieldSize.
Watch out for memory and ensure haproxy has enough resources to work with no issues.
