Subject: [http-state] Something for http-state: a Set-Cookie enhancement that could be potentially rolled out without bumping the spec

From: Paul James Hammant <[email-masked]>
Date: Sat, 23 Oct 2010 10:37:06 -0500

Mark Nottingham (httpbis working group), then Adam Barth suggested I
email this list with an idea.

Basically, I have a small suggestion that could be quite powerful for
small websites that want to improve performance without moving static
content to a different domain.  I've blogged previously here:
http://paulhammant.com/blog/cookies-with-regex-paths.html , and what
follows is the content for that:

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.

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

- Paul Hammant
Principal Consultant / ThoughtWorks

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 23 Oct 2010 17:55:21 +0200

> headers, could benefit from being regular expression.

I'll just make one observation: Regular expressions are complex to  
program, and to get right. I know this, since I once wrote the  
globber/regexp used in the (now removed) SSL certificate hostname regexp  
using Netscape's old syntax for regexps in Common Names. I am quite happy  
that this code is now out of the code.

Additionally, interfacing such a syntax with code already doing regexp for  
something else, might require care in checking the syntax (or complicate  
the code with multimode syntax)

> GMT; path=/*.gif; domain=.example.net

This might just as easily be managed by using path=/gifs/ instead and  
store all resources that require a specific cookie in a dedicated subpath,  
and would not require adding regexp at the browser end.

There is another complication with this as well: The fact that this  
particular syntax will break cookies for every legacy client that does not  
implement it (not just on desktop, but on mobile devices, tvs etc., as  
well) since they will never be able to send a cookie to a server sending  
such a cookie header. If this is to be used, it is necessary that the  
regexp is placed in a separate parameter

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Paul Hammant <[email-masked]>
Date: Sat, 23 Oct 2010 11:05:32 -0500

> I'll just make one observation: Regular expressions are complex to program,
> and to get right. I know this, since I once wrote the globber/regexp used in
> the (now removed) SSL certificate hostname regexp using Netscape's old
> syntax for regexps in Common Names. I am quite happy that this code is now
> out of the code.

My working assumption was that Firefox, IE, Safari, and Opera teams
had a Regex implementation already by virtue of having support for
JavaScript.

> something else, might require care in checking the syntax (or complicate the
> code with multimode syntax)

I'm not sure what you mean there.  The web-app coders only have to
declare regex (for FF/etc to consume). They don't have to
handle/execute regex or iterate through groups.

> This might just as easily be managed by using path=/gifs/ instead and store
> all resources that require a specific cookie in a dedicated subpath, and
> would not require adding regexp at the browser end.

You are right it is a weak example.  A *much stronger* one, would be
the exact opposite: Gifs requests don't need pass cookies back to the
server if served from the same domain.

> implement it (not just on desktop, but on mobile devices, tvs etc., as well)
> since they will never be able to send a cookie to a server sending such a
> cookie header. If this is to be used, it is necessary that the regexp is
> placed in a separate parameter

You guys are the experts.

I had assumed that the change would either be in a HTTP protocol
upgrade or for a known list of supporting agents.  The user agents
that don't support it, could send back cookies with GETs in the
currently understood way (the only difference being that that is more
costly on the wire).  Meaning the fallback situation was compatible.

- Paul

---

From: David Morris <[email-masked]>
Date: Sat, 23 Oct 2010 10:24:41 -0700 (PDT)

> had a Regex implementation already by virtue of having support for

I have found that regex interpreters vary all over the map in both their
own unique definition of regex syntax as well as their unique bugs. It is
hard enough to get a modestly complex regex working when you are actually
in control of the execution engine and can test and debug.

In this case, it is proposed that web 'authors' create a regular 
expression which must be correctly executed by multiple interpreter
platforms and multiple versions of each.

The probablility of success is slim. While a nice objective, I'd
have to oppose adoption based on the fundamental complexity.

Davie Morris

---

From: Paul Hammant <[email-masked]>
Date: Sat, 23 Oct 2010 15:12:09 -0500

Yup, zero-width negative lookahead is going to be a nightmare to write
(and read), even if it executes on all modern browsers. See
http://stackoverflow.com/questions/314639/need-a-regex-to-exclude-certain-strings
and http://bloggingabout.net/blogs/arjen/archive/2008/12/03/regex-exclude-lines-containing-a-specific-word.aspx

Moving away from Regex as is, perhaps some simplified matching format
for a future HTTP:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59
GMT; exclude-paths=*.gif&*.css&*.js&*.png; domain=.example.net

or again, hacked into the current spec for supporting user agents:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59
GMT; path=!(*.gif|*.css|*.js|*.png); domain=.example.net

( I hope I got my De Morgan's right there )

-ph