Re: draft-ietf-httpbis-http2-encryption-10: 2.3. The "http-opportunistic" well-known URI / cache-control

[Kari Hurtta <[e-mail]>]

Martin Thomson <[e-mail]>: (Sun Feb  5 01:57:28 2017)
> On 4 February 2017 at 20:46, Kari Hurtta <[e-mail]> wrote:
> > In other words is client allowed use http-opportunistic response
> > from another alternative service for that purpose, when response
> > was cache-control = no-store ?
> 
> I'd say no.  The same goes for no-cache I think.

With cache-control = no-cache client can use conditional request
for /.well-known/http-opportunistic poll on chosen alternative 
service.

https://tools.ietf.org/html/rfc7234#section-5.2.1.4

| 5.2.1.4.  no-cache
|
|   The "no-cache" request directive indicates that a cache MUST NOT use
|   a stored response to satisfy the request without successful
|   validation on the origin server.

2.3.  The "http-opportunistic" well-known URI
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-10#section-2.3

|   o  That response is fresh [RFC7234] (potentially through revalidation
|      [RFC7232]), and

4.3.1.  Sending a Validation Request
https://tools.ietf.org/html/rfc7234#section-4.3.1

4.3.3.  Handling a Validation Response
https://tools.ietf.org/html/rfc7234#section-4.3.3


|   o  A 304 (Not Modified) response status code indicates that the
|      stored response can be updated and reused; see Section 4.3.4.

So client can use http-opportunistic response for that purpose
from another alternative service when cached response was 
cache-control = no-cache and chosen alternative service
returned 304 (Not Modified) for conditional 
/.well-known/http-opportunistic request.

> > I think that it is not possible to use response from another
> > alternative service on that case and therefore cache-control = no-store
> > implies that client must retrieve /.well-known/http-opportunistic
> > from chosen alternative service.
> 
> That sounds right.

/ Kari Hurtta