Re: [oslc-core] Choice for Configuration context request headder (was: [oslc-core] Agenda for 15 May 2014)

[Ian Green1 <ian.green@uk.ibm.com>]

Hello John
I'm not following your argument here.
 Am I missing something? Caching intermediaries store any Vary headers
on http responses from the origin.  When clients make an http request,
the caching intermediaries look to their caches to see if the request can
be served from cache.  The stored Vary headers are used to check (amongst
other things) whether the cached response is acceptable.

For example, a client does a GET on
a resource in a baseline:

GET /resourceA
Configuration-Context: http://example.com/config1

The response is a version of resourceA
which is immutable.  The server could indicate that the response at
Request-URI "/resourceA" can be cached indefinitely provided
that the request is in Configuration-Context config1.  It would do
this using Vary: Configuration-Context

When "/resourceA" is subsequently
requested with a different value of Configuration-Context (or there is
no such header), the cache entry is not acceptable.  If subsequently
requested with that same Configuration-Context, the response would be served
from cache. 

best wishes,
    -ian

ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational



From:      
 John Arwe <johnarwe@us.ibm.com>
To:      
 oslc-core@lists.oasis-open.org
Date:      
 29/05/2014 14:41
Subject:    
   Re: [oslc-core]
Choice for Configuration context request headder (was:  [oslc-core]
Agenda for 15 May 2014)
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

From Ian> Vary: Link
...But this has a broader scope since
Link values have meaning outside of CM.  I think has some bearing
on the decision on whether or not to use Link or mint a fresh header.

This is true; even in httpbis, Vary is a blunt tool.

The best "counter" I have for this point is that (today) Link is primarily used as a *response* header, whereas Vary-identified headers are tests on the *request* message.  

Technically Link headers are allowed on requests (it takes careful reading of 5988 to even see this), but the only actual usage of this that I'm aware of is in LDP on create (which would not be cacheable responses anyway).

So in near-term practical usage, unlikely to be an issue.  Longer term - which we do have to consider - it's more of a judgement call.  If someone comes up with a request-message Link header that goes viral tomorrow, then the Vary behavior effectively would mean that the config requests were uncacheable by generic caches.  If we were implementing our own caches, of course they could choose to have a deeper understanding of the messages involved.

Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU