Re: OAuth and HTTP caching

 From a quick look, it looks like you use GET to the user  
authorisation URL, at least, so in this case the response could be  
cached. However, if Cache-Control, Expires and Last-Modified are all  
absent, it will only be stored by a few shared caches (e.g., IIS) and  
only reused in unusual circumstances (e.g., the origin is not  
available any more).

As I have said many times before, I don't buy arguments that we have  
to consider environments where people don't have access to HTTP  
headers; while they exist, the intersection of people who want to use  
OAuth and those who absolutely under any condition cannot find a way  
to influence HTTP headers (including changing hosting environments) is  
vanishingly small. All that accommodating these situations does is  
make the argument that people don't need access to headers stronger,  
thereby weakening the Web overall.

That said, the usual approach here is to use a nonce in the URL.  
Completely disallowing caching of a GET response without any access to  
headers isn't possible.

BTW, how does authentication help? Presumably if you can send  
credentials, you can set other headers as well.

Cheers,


On 22/09/2009, at 7:15 AM, Eran Hammer-Lahav wrote:

> As currently written, OAuth use of the HTTP authentication headers  
> is optional at best.
>
> The reason for that was based on concerns that some platforms do not  
> provide access to the HTTP header in either the request or the  
> reply. However, this might have significant ramifications on caching  
> and other parts of HTTP where an indication of an authenticate  
> interaction is needed.
>
> Before the OAuth WG spends any time on discussing the various  
> methods of sending authentication parameters, I would like to find  
> out if using the authentication headers is more of a requirement for  
> such a protocol.
>
> EHL
>


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 22 September 2009 01:49:10 UTC