I’ve realised for the first time a couple of weeks ago that when setting an http cookie, while the domain name is not case sensitive, the path is.
So a while a cookie stored for
http://SomeWebSite.com
can be read using
http://somewebsite.com
a cookie stored for
http://somewebsite.com/SomePath
cannot be read using
http://somewebsite.com/somepath
It would simply not be found.
As this is clearly stated in the RFC (see point 3.3.3 here) I doubt that’s an oversight, but as a user I’m not trained to treat urls as case sensitive text and web servers, as far as I can tell, don’t seem to mind either way, and would serve pages just fine; so I’m left wondering – what is the rationale behind this decision?
Anyone can shed some light?
Most Web servers provide idiot-proof mechanisms. Two common ones I know of are adding slashes to the end of directory names (
http://example.com/x=>http://example.com/x/) and correcting or ignoring casing: (http://stackoverflow.com/ABOUTserves the same ashttp://stackoverflow.com/about). However, this is not a requirement by the Web server, and the browser knows this.http://stackoverflow.com/ABOUTcould be served a completely different page thanhttp://stackoverflow.com/about. Use of GET variables with the ?x=y syntax is popular, and the values are sometimes case sensitive to server scripts. These possible differences must be handled properly by the browser (no caching them as the same document, using different cookie domains, not mangling for Javascript, etc.)