views:

633

answers:

3

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?

+1  A: 

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.

some
Thanks @some, but I'm slightly confused - are you referring to f/s paths or url paths? (you mentioned the path case sensitivity is up to the web server, but the link you have posted refers to f/s paths, I would not have assumed they follow the same rules?!
Yossi Dahan
Since the web-server usually uses a filesystem to retrieve the files from, it usually depends on the OS that the webserver is running on top of.
some
I updated my answer.
some
+8  A: 

Most Web servers provide idiot-proof mechanisms. Two common ones I know of are adding slashes to the end of directory names (http://google.com => http://google.com/) 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.)

strager
so, from a web site development perspective, wouldn't you say it's pretty much meaningless to try and set cookies, say - for customisation or authentication - on a path as there's very little guarantee they would be found...
Yossi Dahan
@Dahan, Not sure what you're asking, but I think you may want to configure your Web server to send a 300 HTTP code to redirect the user to the page with the proper casing, so it's consistent. That way, if a user mistypes the URL (or something), their cookies will still be valid.
strager
A: 

Always treat everything as case sensitive.

Øyvind Skaar
Well, that's not really under my control, which is exactly the issue. both how the web server treats urls (case insensitive in all cases I've seen) and how the browser treats cookie paths has nothing to do with me
Yossi Dahan
Can you at least assume that each user use the same casing when they access the site? For the most part this might be true, as most users take advantage of bookmarks or autosuggestion the second time they access a site.
Øyvind Skaar