Re: [oslc-ccm] Caching versioned resource when passing config context in header

[Nicholas Crossley <nick_crossley@us.ibm.com>]

Martin, the spec is intended to require
that servers support both the header and the query string in the request;
clients may use either. To clarify this, I have added the following text
to my copy of the draft:

A server MUST support both these methods
of passing configuration context.
If a request contains both a header and
a query string, the server MUST use the query string.
Servers SHOULD reject requests that contain
two or more different configuration contexts passed in query strings.

David, your comment about recommending
the use of the Vary header in the response is valid - I'll also add that.

Nick.


From:      
 David Honey <david.honey@uk.ibm.com>
To:      
 "Sarabura, Martin"
<msarabura@ptc.com>
Cc:      
 "OSLC CCM TC (oslc-ccm@lists.oasis-open.org)"
<oslc-ccm@lists.oasis-open.org>
Date:      
 05/11/2016 01:36 AM
Subject:    
   Re: [oslc-ccm]
Caching versioned resource when passing config context in header
Sent by:    
   <oslc-ccm@lists.oasis-open.org>

---

Perhaps one solution to this is for
the response to include a Vary=Configuration-Context header so that different
configuration contexts do not use a previously cached response. If so,
this might be worth mentioning in the Config Mgmt spec.

Best regards, 
David. 



From:        "Sarabura,
Martin" <msarabura@ptc.com> 
To:        "OSLC
CCM TC (oslc-ccm@lists.oasis-open.org)" <oslc-ccm@lists.oasis-open.org>
Date:        2016-05-10
23:16 
Subject:        [oslc-ccm]
Caching versioned resource when passing config context in header
Sent by:        <oslc-ccm@lists.oasis-open.org>

---

Nick et al., I want to make sure I understand this...
https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt/config-resources.html#configcontext
  
If the server accepts a configuration context in the header of the request,
does that mean you've broken caching? Two different requests may ask for
the same resource, each with a different header context, yielding a different
resource. 
  
Also, does the spec provide a method for the client to discover which approach
the service supports? 
  
Thanks, 
  
Dr. Martin Sarabura 
R&D Fellow, PTC 
  
  


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