Re: (rephrasing, sorry for duplicate) | Re: draft-ietf-httpbis-encryption-encoding

Martin Thomson <>: (Tue Jan  3 01:26:26 2017)
> Ahh, so you check and find that it's OK, what about
>  It seems unnecessary once you have authenticated a
> willingness to proceed.
> How about:
> """
> Any authenticated strongly alternative service can provide this
> response. That is, as long as the http-opportunistic response is
> valid, any authenticated alternative service can be used for that
> origin.
> """
> I understand that you might argue that there is safety in checking
> every alternative differently.  That allows all alternatives to be
> configured differently.

However I suppose that alternative services are more or less
required to return same response for same resource. So 
/.well-known/http-opportunistic does not vary.

> I expect that some implementations will likely check every time rather
> than rely on cached values.  More so because - if you rely on your
> cache - you need special logic to avoid caching this resource from
> non-authenticated sources if you do that.  But that's optimization
> territory and optimization is hazardous.
> To that end:
> """
> Clients that use cached http-opportunistic responses MUST ensure that
> their cache is cleared of any responses that were acquired over an
> unauthenticated connection.  Revalidating an unauthenticated response
> using an authenticated connection does not ensure the integrity of the
> response.
> """
> See:
> I am open to arguments that require that the check is performed every
> time, but that's less flexible.  This seems preferable.


Client may want keep track which alternative services succeed
and which failed when reading /.well-known/http-opportunistic

( This does not mean that it needs check 
  on every time. )

Client asks  via http -connection

got Alt-svc for h2=""

tries /.well-known/http-opportunistic from this alternative
service and got 404 (not found)

retrieves  from original connection

got Alt-svc for h2=""

tries /.well-known/http-opportunistic from this alternative
and succeed -- now that is cached (and is retrieved via authenticated connection)

retrieves from this alternative connection


clients asks
(does not matter which connection is used. )

got Alt-svc for h2=""

/.well-known/http-opportunistic   is already valid
(expires on 1 year )

so /.well-known/http-opportunistic need not be probed

Tries retrieve
via alternative service
--- oops broken image ?

That was example where test for h2=""
imply that h2="" was ok even when
test for h2="" says opposite.

Any client, which does that like on my example, 
quite likely is considered to be buggy. Therefore
it may want to keep track for these probes
of /.well-known/http-opportunistic.

/ Kari Hurtta

Received on Tuesday, 10 January 2017 17:05:15 UTC