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/ABOUT serves the same as http://stackoverflow.com/about). However, this is not a requirement by the Web server, and the browser knows this. http://stackoverflow.com/ABOUT could be served a completely different page than http://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.)
If the path is case sensitive or insensitive is up to the web server. Traditionally unix-like OS:s IS case sensitive while MS aren't and that might be reflected in the webservers that are developed on a specified OS.
A link with information about different filesystems that might be of interest.
Update
What resource a URL point to is up to the webserver. http://some.domain.name/myFavouriteThings.txt might be a text file stored on my servers harddisk, but it can also be stored in a database, point to a script that gets executed and returns some random rows. It doesn't even have to be a text file, it could be a picture, video or anything else that can be transferred digitally.
But in this case it is sored as a file on the server. Since the server is a unix-like system, the servers filesystem is case sensitive. Therefore it will only find the file if the case of the request matches the file stored on the disk. If the server had been stored on a MS server, where the file system is case insensitive, the case of the request probably don't matter.
Always treat everything as case sensitive.
