- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 19 Jun 2008 14:50:49 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps@w3.org
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
Received on Thursday, 19 June 2008 21:51:29 UTC