Just a quick thought: Cookies paths, passed up to a browser in HTTP headers, could benefit from being regular expression.

Why?

At the moment the deployers of web applications put static content on different hosts. When GET requests come from the browser, they therefore come without the cookies for the session; Meaning a saving in the number of packets for the request. There is a path setting for cookies that has not changed from day one, but it is only a prefix type of thing. There is nothing in it that you could use to conditionally exclude cookies being sent back with requests. If that were the case, web developers could more easily deploy static and dynamic content on the same host.

The parsing semantics of the Set-Cookie line look pretty basic, and there could be a regex or two that would break it. Maybe, though there is enough utility in ones that do not break the parser, to make this a no-brainer upgrade for browser vendors in advance of any HTTP spec revision. If server developers knew that Mozilla 3.9+, IE 8.3+ understood this regex directive then support for it could be phased in.

Mon, Feb 22, 2010


Update, Oct 2, 2010

Here's an example that would set a cookie pertinent to gifs only. Subsequent non-gif GETs from the browser to the server would not include the cookie:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/*.gif; domain=.example.net

blog comments powered by Disqus

Published

February 22nd, 2010
Reads:

Categories