Re: The HTTP Sec-From Header (draft-abarth-origin)

(Sorry about the broken reply headers, I just joined the list and I'm  
replying from the archives. Also apologies for the duplicate copy to  
the individual recipients, I sent to the wrong list last time.)

Mark Nottingham wrote
> Adam,
>
> One thing -- AIUI Sec-From is sent with *all* requests, including GET.
> Furthermore, servers will make security-related decisions about the
> response based upon it.
>
> As such, won't servers need to set
>
>   Vary: Sec-From
>
> in responses to asure that caches will do the right thing? Otherwise,
> a cache could respond to a cross-site request with a stored response
> improperly.
I think servers will only need to set "Vary: Sec-From" if they  
actually gave a different response based on the Sec-From value. This  
won't be the case for most resources retrieved with GET - only for (a)  
personalized resources that are cross-site accessible (which would  
likely also need to "Vary: Cookie" or  expire immediately for cache- 
correctness), or (b) for resources that are intended to be the target  
of GET-based form submissions, but which must be protected against  
CSRF, which are likely state-changing and therefore need to make  
themselves uncacheable.

I believe these two scenarios are relativel rare, and the vast  
majority of resources won't need to "Vary: Sec-From". The vast  
majority of resources on a typical site do not need Sec-From defense  
against GETs. In fact, resources retrieved by following links or  
directly typing a URL cannot rely on Sec-From at all.

Furthermore, in both scenarios it's likely that the response myst  
already use a Vary header or otherwise be uncacheable.

> The latent problem here, BTW, is that some deployed cache
> implementations don't like Vary headers with any value other than
> 'Accept-Encoding', refusing to cache such responses. This means that
> Sec-From is going to negatively impact caching on the Web, potentially
> quite severely (i.e., some browser as well as intermediary caches
> won't work at all).
I think that in practice, very few GET requests will be affected by  
this. Of those that are, likely they need to be uncacheable anyway.  
Thus, there will be very little impact to caching on the Web.

Regards,
Maciej

Received on Tuesday, 1 September 2009 04:18:23 UTC