Maciej Stachowiak wrote:
After reviewing your comments, I am much more inclined to favor
Microsoft's proposal on this: rename the relevant headers. I think you
argued that this "doesn't scale", but I think only two headers have to
be renamed, "Cookie" and "Authorization". Note that other
authentication-related headers, if any, do not need to be renamed,
because without the "Authorization" header being present, no other
authentication processing will take place. If the headers have different
names, it's very hard to reveal private data accidentally. No site-wide
blanket addition with headers will cause it, you have to go out of your
way to process an extra header and treat it the same as "Cookie". It
would allow allow servers to choose whether to offer personalized or
public data and change their mind at any time, without having to change
clients of the data. It would also work for inclusion of cross-site data
via mechanisms that don't have a convenient way to add an out of band flag.
The only downside I can think of to this approach is that it may break
load balancers that look at cookies, unless they are changed to also
consider the new header ("Cross-Site-Cookie"?).
Another thing that I just realized this won't work for is user-specific
SSL certs. I don't know the specifics here, but the end result is that a
site can tell which user is making the connection by looking at
certificates used when setting up the SSL connection. I don't think this
is widely used today, but it's something that we're hoping to add proper
support for in FF3.1, or the release after that.
In this case, and possibly others, identification isn't done through a
header name that can be changed.
/ Jonas