Subject: RE: draft-ietf-httpbis-http2-encryption-10

From: Mike Bishop <[email-masked]>
Date: Wed, 1 Feb 2017 19:28:28 +0000

I would agree that the changes are pretty substantial, both in text and spirit.  A short second WGLC seems like a good idea.  Everyone give it a fresh read (I'll do likewise) and post any feedback to the list.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2017 10:08 PM
To: Martin Thomson <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; Mike Bishop <[email-masked]>
Subject: Re: draft-ietf-httpbis-http2-encryption-10

I know we're pretty exhausted with this one, but I do observe that the change since WGLC on this one are pretty substantial:
  https://www.ietf.org/rfcdiff?url1=draft-ietf-httpbis-http2-encryption-04&url2=draft-ietf-httpbis-http2-encryption-10

However, Mike is Document Shepherd on this one, so I'll let him make the call as to whether we need another WGLC. Personally, I think if we do have one, a week or so would be sufficient.

Cheers,

> On 1 Feb 2017, at 4:17 pm, Martin Thomson <[email-masked]> wrote:
> 
> I've just posted an update to this doc:
> 
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-encryption/
> 
> This incorporates my best attempt to address the comments Kari had on 
> the last version.  If this is OK, I think that Mark should ask the 
> IESG to publish this as Experimental.
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 2 Feb 2017 18:44:59 +0200 (EET)

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-10#section-2.1

|   HEADERS
|     + END_STREAM
|     + END_HEADERS
|       :method = GET
|       :scheme = http
|       :path = /.well-known/http-opportunistic
|       host: example.com
|
|   HEADERS
|       :status = 200
|       content-type = application/json
|   DATA
|     + END_STREAM
|   [ "http://www.example.com", "http://example.com" ]

To be consistent,

	host: example.com

should be

	host = example.com

But my question is that should this be

	:authority = example.com

instead?  This is client which generates HTTP/2 
requests directly.

https://tools.ietf.org/html/rfc7540#section-8.1.2.3

|   o  The ":authority" pseudo-header field includes the authority
|      portion of the target URI ([RFC3986], Section 3.2).  The authority
|      MUST NOT include the deprecated "userinfo" subcomponent for "http"
|      or "https" schemed URIs.
|
|      To ensure that the HTTP/1.1 request line can be reproduced
|      accurately, this pseudo-header field MUST be omitted when
|      translating from an HTTP/1.1 request that has a request target in
|      origin or asterisk form (see [RFC7230], Section 5.3).  Clients
|      that generate HTTP/2 requests directly SHOULD use the ":authority"
|      pseudo-header field instead of the Host header field.  An
|      intermediary that converts an HTTP/2 request to HTTP/1.1 MUST
|      create a Host header field if one is not present in a request by
|      copying the value of the ":authority" pseudo-header field.

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2017 12:05:36 +1100

> instead?  This is client which generates HTTP/2

Indeed it should.  We should try to keep our examples correct (I think
that I noticed this a while back, then dropped it on the floor).  I
will correct that in the editor's version.

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 4 Feb 2017 11:46:23 +0200 (EET)

Answer of this can be probably deduced from current text and I
do not suggest changes to text.

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

|   This specification defines the "http-opportunistic" well-known URI
|   [RFC5785].  A client is said to have a valid http-opportunistic
|   response for a given origin when:
|
|   o  The client has requested the well-known URI from the origin over
|      an authenticated connection and a 200 (OK) response was provided,
|      and
|
|   o  That response is fresh [RFC7234] (potentially through revalidation
|      [RFC7232]), and
|
|   o  That response has the media type "application/json", and
|
|   o  That response's payload, when parsed as JSON [RFC7159], contains
|      an array as the root, and
|
|   o  The array contains a string that is a case-insensitive character-
|      for-character match for the origin in question, serialised into
|      Unicode as per Section 6.1 of [RFC6454].

|   Allowing clients to cache the http-opportunistic resource means that
|   all alternative services need to be able to respond to requests for
|   "http" resources.  A client is permitted to use an alternative
|   service without acquiring the http-opportunistic resource from that
|   service.
|
|   A client MUST NOT use any cached copies of an http-opportunistic
|   resource that was acquired (or revalidated) over an unauthenticated
|   connection.  To avoid potential errors, a client can request or
|   revalidate the http-opportunistic resource before using any
|   connection to an alternative service.

5.2.1.5.  no-store
https://tools.ietf.org/html/rfc7234#section-5.2.1.5

|   The "no-store" request directive indicates that a cache MUST NOT
|   store any part of either this request or any response to it.  This
|   directive applies to both private and shared caches.  "MUST NOT
|   store" in this context means that the cache MUST NOT intentionally
|   store the information in non-volatile storage, and MUST make a
|   best-effort attempt to remove the information from volatile storage
|   as promptly as possible after forwarding it.

If alternative servers uses

   HEADERS
       :status = 200
       content-type = application/json
       cache-control = no-store
   DATA
     + END_STREAM
   [ "http://www.example.com", "http://example.com" ]

on all /.well-known/http-opportunistic responses, can server assume 
that client probes chosen alternative service for
/.well-known/http-opportunistic before starting using it.

2.1.  Alternative Server Opt-In
https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-10#section-2.1

|   purposes of {RFC7838}}.  In addition to authenticating the server,
|   the client MUST have obtained a valid http-opportunistic response for
|   an origin (as per Section 2.3) using the authenticated connection.

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

But of course I can be wrong.

/ Kari Hurtta

( Seems that "alternative server" and "alternative service"
  are used on interchangeably. )

---

From: Martin Thomson <[email-masked]>
Date: Sun, 5 Feb 2017 10:57:28 +1100

> was cache-control = no-store ?

I'd say no.  The same goes for no-cache I think.

> from chosen alternative service.

That sounds right.

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 5 Feb 2017 10:23:22 +0200 (EET)

Martin Thomson <[email-masked]>: (Sun Feb  5 01:57:28 2017)
> 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.

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.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 6 Feb 2017 20:35:19 +0200 (EET)

> the last version. 

Looks ok.

This may also imply that, if server does not allow caching 
http-opportunistic  resource, client need acquiring the 
http-opportunistic resource from chosen alternative service 
before using it. If server does that kind conclusion, this 
looks still ok. ( That was my question about cache-control 
= no-store. ) 

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Feb 2017 09:49:00 +1100

> looks still ok. ( That was my question about cache-control

Yep.  That's a natural consequence of the requirements we have in place.