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

Martin Thomson <martin.thomson@gmail.com>: (Tue Jan  3 01:26:26 2017)
> Ahh, so you check alt1.example.com and find that it's OK, what about
> alt2.example.com?  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: https://github.com/httpwg/http-extensions/pull/279
> 
> I am open to arguments that require that the check is performed every
> time, but that's less flexible.  This seems preferable.

hmm.

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 
  /.well-known/http-opportunistic
  on every time. )


Client asks http://example.com/  via http -connection

got Alt-svc for h2="a1.example.com:443"

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

retrieves http://example.com/img/logo.png  from original connection

got Alt-svc for h2="a2.example.com:443"

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

retrieves http://example.com/img/background.png from this alternative connection


Later

clients asks http://example.com/page.html
(does not matter which connection is used. )

got Alt-svc for h2="a1.example.com:443"

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

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


Tries retrieve http://example.com/img/map.png
via a1.example.com alternative service
--- oops broken image ?


That was example where test for h2="a2.example.com:443"
imply that h2="a1.example.com:443" was ok even when
test for h2="a1.example.com:443" 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