On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote:
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"?).
Using different header names would certainly address the concern I
have regarding reducing the risk that private data is inadvertently
leaked.
However I think the downsides are pretty big. The load balancer
issue you bring up is just one example. Another is that I think
caching proxies today avoid caching data that is requested using
Authentication headers. Probably the same is true for the cookie
header in some configurations.
I think going against the HTTP spec carries big unknown risks. I'm
sure others with more HTTP experience than me can chime in here
better.
I don't see how this would go against HTTP. It's perfectly valid HTTP
to not send "Cookie" or "Authorization" headers, and also valid to
send whatever custom headers you want if agreed upon with the server.
The cost and risk of adding an extra boolean to XMLHttpRequest seems
much lower.
The cost of tying server-side changes to client-side changes for a
cross-site communication technology seems like a very high cost to me.
I don't buy the argument that it's normal to change when you change
what data you are reading - the data being personalized (or not) is a
different kind of change from changing the type of data you read. To
compare to the user-level example, GMail and GCal are different URLs,
but nytimes.com is the same URL whether I'm logged in or not.
Regards,
Maciej
