W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 20 Mar 2014 11:17:41 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C0974C36-16C1-44AB-819F-166E8F9DC209@mnot.net>
To: "William Chan (陈智昌)" <willchan@chromium.org>

On 20 Mar 2014, at 5:54 am, William Chan (陈智昌) <willchan@chromium.org> wrote:

> There was some discussion about this at the IETF89 httpbis session, and I see that there's an altsvc branch in the github http2 repo (https://github.com/http2/http2-spec/commits/altsvc) with a commit (https://github.com/http2/http2-spec/commit/0afe05385c2a521079ba3874a20a21ebb1debd99) that marks this draft as a normative reference.

There's also a revised httpbis-alt-svc in the works:
  https://github.com/mnot/I-D/tree/master/httpbis-alt-svc

... which you really need to read when looking at that branch.

Neither has yet been brought to the WG; I'm still working on them in consultation with Martin, Patrick and Julian (but almost done).


> I wanted to doublecheck what peoples' thoughts on this matter were. I feel like there was some form of rough consensus assessed in the session, although the exact details were very ambiguous to me. Currently the alt-svc draft lists 4 use cases that could be addressed with various proposals:
> 
> (1) Upgrading HTTP/1 (" The first use case for Alternate Services is upgrading a client from HTTP/1 to HTTP/2 for http:// URIs (i.e., without the use of SSL or TLS).") as an alternative to HTTP Upgrade.
> (2) Using TLS with http:// URIs
> (3) Mitigating Load Asymmetry
> (4) Segmenting Clients that Support TLS SNI
> 
> There are two mechanisms proposed for addressing these use cases. They are the ALTSVC HTTP/2 frame and Alt-Svc HTTP response header.
> 
> My personal gauge of the rough consensus at the IETF89 httpbis session was there was rough consensus for meeting use cases (3) and (4), both of which require the ALTSVC frame, but not the Alt-Svc response header. Furthermore, I think there was rough consensus around incorporating the ALTSVC frame directly into the core HTTP/2 spec, although I remember Rob's disagreement here (thinking that we should bring back extensible frames, and if that doesn't get in, we use should MAY rather than SHOULD in the spec as to how clients should handle this advisory frame).
> 
> I think that use case (1) did not get discussed at all

Correct. I suspect we'll get to that, if the folks who are interested in doing h2c want to.


> , and (2) got raised very briefly by Pat, but tabled due to lack of time.

No, we discussed it pretty extensively; look at the minutes:
  https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#315-http-uris-over-tls
  https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#alt-svc-http-header-field
  https://github.com/http2/wg_materials/blob/master/ietf89/minutes.md#discovery-of-tls-support-for-http-uris


> Both these use cases rely on the Alt-Svc HTTP response header. I therefore do not believe there's a rough consensus on including the Alt-Svc HTTP response header. But perhaps further discussion will reach such a consensus.

My impression at the meeting was that we roughly agreed to document how to use TLS for http:// URIs without requiring it, which means we need the Alt-Svc header. I discussed this with Martin and Julian, and we agreed that we'd put that in the alt-svc document, since it's separable (and potentially applicable to HTTP/1 for other use cases); that is what we're about to propose to the WG.

From a judging consensus standpoint -- of course we can talk about it more. However, I will note that there's a *significant* amount of interest in this mechanism from many in the security community, we have an implementation in one major browser, and it's not required to implement or use. So, my feeling is that an argument to omit it from the document is going to need to be a very persuasive one -- one that's stronger than "we think it's a bad idea." 

One way to do that would be to get "don't do this" advice from the Security Area, but so far all of the input I've had from that direction is "do this."


> I'd like to hear thoughts from folks on, what parts of the alt-svc draft would be acceptable for inclusion in the HTTP/2 core spec or as a normative reference.
> 
> FWIW, my thought would be to include the ALTSVC frame in the core spec, with a normative reference to a standalone specification of section 3.1 in the alt-svc draft.

Will, please be patient and wait until we actually have a proposal (a few hours to a day, I think); basing discussion on work-in-progress is not going to be helpful.

Thanks,

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 20 March 2014 00:18:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC