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

Martin Thomson <martin.thomson@gmail.com>: (Wed Jan 11 09:52:45 2017)
> Thanks for confirming.  I think that this closes the issue.  Is that right?


This feels like trap. Perhaps no normative requirement, but some 
warning may be on place (both clients implementators and server
administrators).

https://github.com/httpwg/http-extensions/blob/35609f8d621a3156031a93a5b118d53a5696f396/draft-ietf-httpbis-http2-encryption.md#the-http-opportunistic-well-known-uri-well-known

You added note about another trap:

| 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.

Perhaps:

  Using cached http-opportunistic responses as only criteria for accepting
  provided alternative service can lead situation where alternative
  server, which previously failed to provide /.well-known/http-opportunistic,
  is used by client.

  ( And something about that client can ignore any alternative service even
    when it accpets some other alternative services. And someting that
    server administartor need ensure that all alternative services are
    equally capable. )


This almost feel like that /.well-known/http-opportunistic need
to be cached separately for different alternative servises, but
think that this is not allowed. At least that becomes messy.

> (And don't worry about the title, I saw draft-ietf-..... and didn't
> even notice.)

I probably looked that there was "encyption" on somewhere on name:
'draft-ietf-httpbis' + 'encryption'. 

That is somewhat confusing when there
is now two draft with that pattern.

/ Kari Hurtta
 
> On 11 January 2017 at 19:37, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> > Martin Thomson <martin.thomson@gmail.com>: (Wed Jan 11 00:29:30 2017)
> >> On the one hand, if a server advertises alternatives that are broken,
> >> that really is a server problem.  On the other, clients do these sorts
> >> of things all the time to improve robustness, so that's entirely
> >> reasonable to do.  I just don't think we need to *require* it.
> >
> > Yes, client needs that "Opportunistic Security for HTTP"
> > (draft-ietf-httpbis-http2-encryption) only to improve robustness.
> >
> > Otherwise "HTTP Alternative Services" (RFC7838) is enough.
> >
> > ( Seems that I have "draft-ietf-httpbis-encryption-encoding"
> >   on subject when it should be "draft-ietf-httpbis-http2-encryption".
> >   Paste error? )
> >
> > On the other hand "Opportunistic Security for HTTP" need specify
> > only that part where collaboration between client and server
> > is needed.
> >
> > / Kari Hurtta

Received on Thursday, 12 January 2017 05:17:03 UTC