- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 30 Jun 2008 16:42:46 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: public-webapps@w3.org
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
Received on Monday, 30 June 2008 23:44:15 UTC