Subject: I-D Action: draft-ietf-httpbis-http2-09.txt

From: [email-masked]
Date: Wed, 04 Dec 2013 11:58:43 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Bis Working Group of the IETF.

	Title           : Hypertext Transfer Protocol version 2.0
	Author(s)       : Mike Belshe
                          Roberto Peon
                          Martin Thomson
                          Alexey Melnikov
	Filename        : draft-ietf-httpbis-http2-09.txt
	Pages           : 64
	Date            : 2013-12-04

Abstract:
   This specification describes an optimized expression of the syntax of
   the Hypertext Transfer Protocol (HTTP).  HTTP/2.0 enables a more
   efficient use of network resources and a reduced perception of
   latency by introducing header field compression and allowing multiple
   concurrent messages on the same connection.  It also introduces
   unsolicited push of representations from servers to clients.

   This document is an alternative to, but does not obsolete, the
   HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.

   This version of the draft has been marked for implementation.
   Interoperability testing will occur in the HTTP/2.0 interim in
   Zurich, CH, starting 2014-01-22.  This replaces -08, which was
   originally identified as an implementation draft.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpbis-http2-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-http2-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 12:11:24 -0800

Yes, we apologize for the delay in getting this all ready, but it's out now.

The delta over -08 is minimal:
 - We've added the fix that preserves the ordering of header fields
with the same name
 - The Cookie header field can now be split, and MUST be reassembled
 - We've expanded the text on 1xx
 - This now references compression-05.

There are, of course, larger changes in the compression spec.

This now covers everything that was agreed upon at the last meeting
for implementation.  I hope that it's not too late.  Please note:

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Dec 2013 10:25:05 +1100

Thanks Martin, Herve and Roberto.

I've updated the HTTP2 page to denote this as our official third implementation draft:
  http://http2.github.io/#implementations

Diffs from the previous drafts are:
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-http2-09.txt
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-header-compression-05.txt

Cheers,

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

---

From: James Cloos <[email-masked]>
Date: Wed, 04 Dec 2013 19:40:25 -0500

It would be useful for §3.2 (Starting HTTP/2.0 for “http” URIs) also to
include an example of combining HTTP/1.1 → HTTP/2.0 upgrade with rfc 2817
style cleartext → TLS upgrade.  Without, that is, relying on ALPN after
the 2817 upgrade to get to HTTP/2.0.

Even though 2817 hasn’t gotten much use on port 80, it isn’t entirely
unused and the ability to jump directly to 2.0/tls will be welcome where
2817 is used.

An example, therefore, also would be welcome.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 5 Dec 2013 06:51:04 +0200

>  - We've expanded the text on 1xx

Is that text on 1xx (specifically on translation behaviour) in accordance
with HTTP/1.1 specs?

Also, If HTTP/1.1 (only!) client tries to do large streaming PUT/POST
to possibly auth'd URL, and there is a proxy that does that sort of
games, things just plain are going to fail.

Also, large streaming PUT/POST to possibly auth'd URL can't be done
without expect-100 nor resorting to heuristic timeouts (framing
will not help here, apart from being able to send your buffers while
waiting, and with any sort of faster link, those buffers are going
to run out, forcing transfer pause).

The problem is that there is a point of no return in such thing,
once past that, any error causes a failure without application being
to able to adjust the request (e.g. by adding authentication).

In HTTP/1.1, such app would presumably use zero buffers, so point
of no return is actually starting to send the data.

-Ilari

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Dec 2013 17:09:50 +1100

> games, things just plain are going to fail.

What do you mean by "that sort of games" here?

> to run out, forcing transfer pause).

The server can send a final status code at any time, with HTTP/1 or HTTP/2. The client can choose whether to start sending the body or hold back, both with HTTP/1 and HTTP/2. 

> to able to adjust the request (e.g. by adding authentication).

Changing the request headers after the header block has terminated isn't possible in HTTP/1 (I mean, theoretically you could add trailers, but AFAIK this is completely un-interoperable).

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 5 Dec 2013 08:37:15 +0200

> What do you mean by "that sort of games" here?

Synthetizing 100 response (yes, that would also happen with HTTP/1.0
servers, but usually people aren't doing PUT/POST of large things to
those).

> The server can send a final status code at any time, with HTTP/1 or HTTP/2.
> The client can choose whether to start sending the body or hold back, both
> with HTTP/1 and HTTP/2. 

Well, final status codes mid-body are somewhat unlikely, and would likely
be caused by problems in the body itself (or server bugs).

Without positive acknowledgement one needs to timeout on success case
before one can send unbuffered part.

Yes, often the whole transfer can be buffered (or the data regenerated),
but not always.

> Changing the request headers after the header block has terminated
> isn't possible in HTTP/1 (I mean, theoretically you could add trailers,
> but AFAIK this is completely un-interoperable).

If you still have the data needed to form a request, you can send another
one with problems (e.g. lack of auth) fixed.

But after certain point in some cases, one can't do that anymore.

-Ilari

---

From: Michael Sweet <[email-masked]>
Date: Thu, 05 Dec 2013 11:04:07 -0500

Mark,

On Dec 5, 2013, at 1:09 AM, Mark Nottingham <[email-masked]> wrote:
>> ...

Keep in mind that for POST and PUT, servers should not send successful status codes (2xx) until the client has provided all of the message body for the request. Among other things, doing so prevents the server from accurately reporting status and prevents pipelining from working at all.  And it does *bad* things with many clients/proxies that think a 200 OK response means they can stop sending data...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 10:06:45 -0800

On 5 December 2013 08:04, Michael Sweet <[email-masked]> wrote:
> Keep in mind that for POST and PUT, servers should not send successful status codes (2xx) until the client has provided all of the message body for the request.

Should not?  I disagree.  If the response does not depend on the rest
of the body, it's safe to send the response.

In HTTP/1.1, that might be inadvisable due to the bugs you describe.
However, in HTTP/2.0 a client can take the response, cancel the stream
and save the bytes without hurting anything else.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 10:11:22 -0800

> before one can send unbuffered part.

Yes, this is correct.  Losing 100 means that you don't get an
acknowledgement.  But why would you hold back?  The server has a
receive window that protects it from unwanted request bodies; just
send.  If it doesn't want it, you will get a response or a stream
cancellation.

Note that a server that wants 100 continue-equivalent behaviour can
set an initial window size for stream of zero.

The only drawback is for clients that want to save bytes.  Those
clients can implement a timeout of ~1RTT if they want to avoid that
cost.  That's the only downside from removing 1xx support.  There's a
lot of upside though.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 05 Dec 2013 13:13:37 -0500

Martin,

> of the body, it's safe to send the response.

True, but I've never seen a PUT or POST that does not depend on the whole request body to (safely) determine success.  (I probably should have said "generally should not" or something along those lines, but that felt a bit too wishy-washy at the time...)

> and save the bytes without hurting anything else.

Right, that's one of the many reasons why I am excited about HTTP/2.0.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 10:18:54 -0800

On 5 December 2013 10:13, Michael Sweet <[email-masked]> wrote:
> True, but I've never seen a PUT or POST that does not depend on the whole request body to (safely) determine success.

I have :)  There are a few cases where I've ignored POST bodies
because there was nothing that I could sensibly do with the
information, or I knew that I was going to ignore it.  Actually quite
a few cases.  Think "my policy says that you get X, no matter what".
It's usually not that much data to ignore, but the response was 200 or
201 in most cases (though it could still be 4xx or 5xx).

---

From: Mike Bishop <[email-masked]>
Date: Thu, 5 Dec 2013 18:22:09 +0000

Do you still expect to receive the remainder of the client body to store it somewhere, or is the body totally disregarded?

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, December 5, 2013 10:19 AM
To: Michael Sweet
Cc: Mark Nottingham; Ilari Liusvaara; HTTP Working Group
Subject: Re: I-D Action: draft-ietf-httpbis-http2-09.txt

> True, but I've never seen a PUT or POST that does not depend on the whole request body to (safely) determine success.

I have :)  There are a few cases where I've ignored POST bodies because there was nothing that I could sensibly do with the information, or I knew that I was going to ignore it.  Actually quite a few cases.  Think "my policy says that you get X, no matter what".
It's usually not that much data to ignore, but the response was 200 or
201 in most cases (though it could still be 4xx or 5xx).

---

From: James M Snell <[email-masked]>
Date: Thu, 5 Dec 2013 10:24:47 -0800

+1... I have many cases where we abort based on nothing but
Content-Type and other headers, without ever actually looking at the
body of the post. If we can fail fast and cancel the body, then
fantastic.

(of course, multiplexing sequences of non-idempotent / non-safe
methods is extremely tricky in itself, but that's a separate issue..
developers need to be aware that just because they receive a response
code, doesn't mean it's ok to fire off the next request...)

- James

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 5 Dec 2013 22:11:18 +0200

> cost.  That's the only downside from removing 1xx support.  There's a

Well, and clients that fail if any error happens after >N (including
case where N=0) bytes have been sent. Whereas for errors before
that point, the client can auto-resubmit with header modifications
(e.g. adding authentication).

And yes, such things do exist. And the standard way to handle this in
HTTP/1.1 is Expect: 100-Continue (plus maybe hacks for servers that
don't support it, the proper term for such hacks tends to be "Charlie
Foxtrot").

This is not about saving bytes nor roundtrips. 

As for doing this even with special server support in HTTP/2.0, how
could server signal (including through (most) middleboxes!) that it
considers sent headers OK (NAKing can be done with sending final response)?
New end-to-end frame type (of course, most client APIs are probably not
going to like that...)?

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Dec 2013 12:49:35 -0800

> Do you still expect to receive the remainder of the client body to store it somewhere, or is the body totally disregarded?

If I needed the body, I wouldn't send a response before it's in.  Then
I wouldn't be done :)