Subject: Expect: + Upgrade: = ...

From: Daniel Stenberg <[email-masked]>
Date: Mon, 2 Sep 2013 23:53:42 +0200 (CEST)

Hi all,

Suppose a client would do an HTTP POST to a http:// server that supports HTTP 
2.0, and it would send both an "Expect: 100-continue" _and_ an "Upgrade: 
HTTP/2.0" header.

Should we make it so that if a 101 is responded first, the rest of the POST 
upload should be done using HTTP2 but if we instead get a "100 continue" 
first, we go on and send the data using HTTP?

I guess another way would be to just not send both headers in the same 
request! =)

-- 

  / daniel.haxx.se

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Sep 2013 10:59:40 -0700

> I guess another way would be to just not send both headers in the same

That's what I'm thinking.  Though 101 followed by 100 sounds tempting
because you would get flow control, it sort-of violates the HTTP/1.1
framing.

Mark currently has an issue around 100-continue
(https://github.com/http2/http2-spec/issues/18).  I'm deferring to him
on this matter.  I think that the direction we were heading was
something like: 100-continue + HTTP/2.0 = no.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 4 Sep 2013 10:39:58 +0200 (CEST)

On Tue, 3 Sep 2013, Martin Thomson wrote:

> I think that the direction we were heading was something like: 100-continue 
> + HTTP/2.0 = no.

Yes. I don't have any big problem with that other than the fact that when I 
introduce http2 support to curl, it will make the request act a little 
different if the user asks for it to go over http2 rather than using vanilla 
http - for the rare servers that actually does something sensible with 
100-continue...

A command line example to a server that rejects a POST would be:

   curl --http2.0 -d @largishfile http://example.org/

vs

   curl --http1.1 -d @largishfile http://example.org/

This client can't have any prior knowledge about HTTP2 support and this is a 
POST done as first request with large body...

The effect seems to risk a little more data waste in the HTTP+upgrade case.

I won't lose any sleep over it. =)

-- 

  / daniel.haxx.se

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Sep 2013 09:30:43 -0700

> The effect seems to risk a little more data waste in the HTTP+upgrade case.

Yeah, I'm thinking that for https: URLs it's easy.  ALPN means that
there is no probing.  And you get the option to use flow control.  In
fact, that's actually much nicer.

For http: URLs, it's a little trickier.  You might do a HEAD request
for the upgrade request, followed by a POST after the upgrade
completes.  That's round trips still, and if the upgrade fails, it's
even worse.  Though, I'll note that it's still the same speed in the
success case as the https: URL case ...

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 4 Sep 2013 23:29:19 +0200 (CEST)

On Wed, 4 Sep 2013, Martin Thomson wrote:

> Yeah, I'm thinking that for https: URLs it's easy.  ALPN means that there is 
> no probing.  And you get the option to use flow control.  In fact, that's 
> actually much nicer.

Yes I agree that the https method of deciding protocol is nicer and less 
problematic. But I forsee a future where people will use the same operations 
like today but only enable http2, and then the URL will remain as-is which 
often means http://.

> For http: URLs, it's a little trickier.  You might do a HEAD request for the 
> upgrade request, followed by a POST after the upgrade completes.  That's 
> round trips still, and if the upgrade fails, it's even worse.  Though, I'll 
> note that it's still the same speed in the success case as the https: URL 
> case ...

I've already been burned in the past trying to do HEAD when a POST is asked 
for. There are unfortunately too many servers out there that accept POST but 
refuse HEAD for the same URI so it isn't a way I would like to go either...

But again, I don't think this is a big problem.

-- 

  / daniel.haxx.se

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 05 Sep 2013 20:29:53 +1200

On 3/09/2013 9:53 a.m., Daniel Stenberg wrote:
> Hi all,
>
> Suppose a client would do an HTTP POST to a http:// server that 
> supports HTTP 2.0, and it would send both an "Expect: 100-continue" 
> _and_ an "Upgrade: HTTP/2.0" header.
>
> Should we make it so that if a 101 is responded first, the rest of the 
> POST upload should be done using HTTP2 but if we instead get a "100 
> continue" first, we go on and send the data using HTTP?
>

I do not think so. If for any reason the client sends Expect then the 
payload anyway (happens) or times out and starts sending anyway before 
101 arrives you will end up with a corrupted HTTP/2 data flow and be 
worse off than just using HTTP/1. Particularly since this client is 
already signalling it wants to use the HTTP/1.1 fairly efficiently.

IMO when retaining that payload as HTTP/1 it is reasonable to expect 
either one to come back. Order does not matter due to the directionality 
of the traffic. In fact keeping it as HTTP/1 chunked will allow the full 
use of bandwidth of the connection to maximise speed reaching the end of 
it and be no less efficient than a HTTP/2 connection with single request 
on it sending DATA frames.

Note that Upgrade is specifying that the *response* will be in HTTP/2 
format. Expect: is specifying that the *request* payload will be 
delayed. RFC 2616 indicates that the HTTP/2 traffic from client only 
begins after that request (including payload) is completed.

Amos

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 5 Sep 2013 05:14:26 -0700

On Sep 5, 2013, at 1:29 AM, Amos Jeffries wrote:

>> Suppose a client would do an HTTP POST to a http:// server that supports HTTP 2.0, and it would send both an "Expect: 100-continue" _and_ an "Upgrade: HTTP/2.0" header.
>> 
>> Should we make it so that if a 101 is responded first, the rest of the POST upload should be done using HTTP2 but if we instead get a "100 continue" first, we go on and send the data using HTTP?
>> 
>> I guess another way would be to just not send both headers in the same request! =)
>> 
> 
> I do not think so. If for any reason the client sends Expect then the payload anyway (happens) or times out and starts sending anyway before 101 arrives you will end up with a corrupted HTTP/2 data flow and be worse off than just using HTTP/1. Particularly since this client is already signalling it wants to use the HTTP/1.1 fairly efficiently.
> 
> IMO when retaining that payload as HTTP/1 it is reasonable to expect either one to come back. Order does not matter due to the directionality of the traffic. In fact keeping it as HTTP/1 chunked will allow the full use of bandwidth of the connection to maximise speed reaching the end of it and be no less efficient than a HTTP/2 connection with single request on it sending DATA frames.

Right, we cannot rely on the client receiving the 100 or 101 before it
starts sending the body data.  In any case, it is very unlikely that a
client's first request to a server is a big POST.

....Roy

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 5 Sep 2013 18:17:14 +0200 (CEST)

On Thu, 5 Sep 2013, Roy T. Fielding wrote:

> In any case, it is very unlikely that a client's first request to a server 
> is a big POST.

For a browser sure. For curl and libcurl users that's a fairly common use 
case. Or at least not a rare one.

-- 

  / daniel.haxx.se

---

From: Michael Sweet <[email-masked]>
Date: Thu, 05 Sep 2013 13:17:05 -0400

On Sep 5, 2013, at 12:17 PM, Daniel Stenberg <[email-masked]> wrote:
>> In any case, it is very unlikely that a client's first request to a server is a big POST.
> 
> For a browser sure. For curl and libcurl users that's a fairly common use case. Or at least not a rare one.

and for CUPS and IPP...

However, like I said here and on the mailing list, since the client doesn't have to tear down the whole connection after a failed HTTP/2.0 POST request like it would for a failed HTTP/1.1 POST request, and since there is no guarantee that the client will get the initial status response before it decides to send the request body, dropping Expect support in HTTP/2.0 isn't the end of the world.  We should just make it clear that clients SHOULD stop sending the request body as soon as a status other than 100 is received from the server since, at that point, the stream will likely have been closed by the server.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 5 Sep 2013 11:13:58 -0700

> For a browser sure. For curl and libcurl users that's a fairly common use case. Or at least not a rare one.

Yes, and in that case there is no value gained from changing
to HTTP/2 before the body is sent.  Having a command-line option
to use HTTP/2 from the start (without Upgrade) makes sense.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 5 Sep 2013 11:17:02 -0700

>> For a browser sure. For curl and libcurl users that's a fairly common use case. Or at least not a rare one.

which, again, will gain nothing from switching to HTTP/2 before
the initial request body is sent.

Using both Expect: 100-continue and Upgrade, at the same time,
will work fine -- it can be implemented as already specified.
100 is required to be sent first.

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Sep 2013 13:30:31 -0700

> 100 is required to be sent first.

Reading http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#section-6.7,
this wasn't obvious, should it be?

No question that it is the right thing to do: complete the HTTP/1.1
request before proceeding with the next protocol; otherwise the client
side of the connection is in an indeterminate state.  (It needn't be,
but the alternative would depend on 100-continue being consistently
implemented, and we know that hasn't happened.)

---

From: Roberto Peon <[email-masked]>
Date: Thu, 5 Sep 2013 13:43:55 -0700

That would be potentially problematic in some ways, as you really do want
to be in the http/2 context for the response.
We could solve some of this by stating that you must not have expect:
continue when upgrading to http/2.

-=R

On Thu, Sep 5, 2013 at 1:30 PM, Martin Thomson <[email-masked]>wrote:

> Reading
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23#section-6.7,

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Sep 2013 14:01:47 -0700

On 5 September 2013 13:43, Roberto Peon <[email-masked]> wrote:
> That would be potentially problematic in some ways, as you really do want to
> be in the http/2 context for the response.

"That" being what specifically?

The response is sent in HTTP/2.0, but the point was that the *request*
is in HTTP/1.1.

> continue when upgrading to http/2.

Roy's point here, I think, is that expect: 100-continue has to come
before upgrade: foo, in all cases.  We could prohibit the combination
too, but perhaps there is no need.  I suspect that anyone with any
sense will try to avoid this combo anyway.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 5 Sep 2013 14:07:39 -0700

ok, I lol'd at that, but I'm willing to admit that the combination is
silly, and that implementations that my proxies are likely to encounter
will get it right in the vast majority of the time.

However, I imagine that many folks would get this wrong if they don't pay
attention to it specifically.
-=R

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Sep 2013 14:14:11 -0700

On 5 September 2013 14:07, Roberto Peon <[email-masked]> wrote:
> ok, I lol'd at that, but I'm willing to admit that the combination is silly,
> and that implementations that my proxies are likely to encounter will get it
> right in the vast majority of the time.

I think that it's easy to say: 'do it this way, or don't do it at
all'.  It might be easier to say 'don't do it at all', but I'm not
seeing a strong need to do so.

Note that any implementation that supports upgrade will have to deal
with the possibility that the request also has expect: 100-continue.
The real onus is on the proxy or server to get it right, (or to say
gtfo).

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Sep 2013 00:15:40 +0200

> this wasn't obvious, should it be?

I see no alternative in fact. Anyone in the chain may emit a 100
and the client has to be prepared to drain any number it sees before
a final response. 101 is not final, but it's half-way to the final
one.

Regards,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Sep 2013 16:19:31 -0700

> a final response. 101 is not final, but it's half-way to the final

I see no alternative either, but it's probably not clear to everyone
that all the 100s come before the 101.

It really just makes we wonder just how easily generalized the
handling for the 1xx series is in practice.  Maybe it's just that 101
has to be the last 1xx, or maybe it's that 100 has to be before any
others, or maybe it's just this specific pair of status codes.

Either way, I would like to see it documented.  I'm happy to propose
text for httpbis if that helps, but I'm not sure that I'm qualified.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Sep 2013 08:29:17 +0200

> that all the 100s come before the 101.

First, nothing in the text makes this obvious (at least to me). Second,
the usual rule applies : it was not obvious to at least one implementer,
which is a very good reason to try to make it clearer, otherwise we're
at risk of seeing various implementations guess differently.

> others, or maybe it's just this specific pair of status codes.

Well, it's a bit of all of this since we have only two 1xx. I'd still
say that 100 is the first one because any unknown 1xx code has to be
handled as 100 (by definition). So in practice nothing has to be said
about 100, we're in the default situation. And 101 necessarily is the
last one because we're supposed to be talking a different protocol
just after it, whose framing is unknown to 1.1 implementations.

> text for httpbis if that helps, but I'm not sure that I'm qualified.

Well maybe start with something along these lines ?

   http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-6.2.1

   If a server wants to receive a request payload body before deciding to
   switch the protocol, it may have to send a 100-continue interim response
   first, according to the rules in 6.2.1.

   A client waiting for a 101 status code to upgrade the protocol must still
   be prepared to handle other 1xx interim responses first before receiving
   the 101 status code confirming the protocol upgrade.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 06 Sep 2013 23:23:10 +1200

>     the 101 status code confirming the protocol upgrade.

Holdup.

There is nothing preventing the server emitting further 100 status 
frames inHTTP/2 format.

So like I said 100 and 101 can occur in any order. There is no reason 
for the order of them to have any effect on the transaction as a whole. 
101 has no effect on the *request* bytes and 100 has no effect on the 
*response* bytes. Why are people seeing any problem here at all?

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Sep 2013 13:55:26 +0200

Hi Amos,

> There is nothing preventing the server emitting further 100 status 

I have absolutely no problem with this obviously and it is 100% compatible
with the text due to the word "before" in the first sentence.

> So like I said 100 and 101 can occur in any order.

This statement is confusing because it cancels any notion of HTTP version. In
1.1 we cannot have 100 after 101. However we can have a 101 in 1.1 followed
by a 100 in 2.0, just as we could have an SSH banner after a 101 switching to
any other protocol. The HTTP/1.1 protocol terminates upon 101 to switch to
another protocol. And this other protocol is free to do whatever it finds
suitable.

> There is no reason 

I think because they fear they'd have to send the body in 1.1 framing format
instead of 2.0 framing format or conversely depending on the order, which is
wrong. If you get a 100 in 1.1, obviously it's before the 101 upgrade (since
the interim response 101 terminates at the double CRLF which marks the switch)
so you must post the body in 1.1 framing form. If a server finds it more
appropriate to switch first then get the data in whatever other protocol it
likes, it should upgrade first then ask for the data.

I remember Roy insisting a lot on 101 being an interim response during the
work on the WebSocket spec. Here we can see how much sense it makes : the
client knows that only the protocol has switched but the request has not
yet been processed. So the client which has not posted a payload and sees
a switch might still have to post a payload if required to do so by the
next protocol rules, with it being a 100 or an implicit unconditional send.

That's why I think there is no problem at all. However it might not be
obvious to get right initially, as Daniel reported.

Regards,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 10:35:45 -0700

On 6 September 2013 04:23, Amos Jeffries <[email-masked]> wrote:
> There is nothing preventing the server emitting further 100 status frames
> inHTTP/2 format.

100, or 1xx?

I thought that the text was good.  It specifically doesn't say
anything about what happens in the upgraded protocol, because that's
the business of that protocol.  For HTTP/2.0, I guess that in theory
you might get more 1xx status codes, but you won't get 100, because
we're prohibiting that.

> So like I said 100 and 101 can occur in any order. There is no reason for
> the order of them to have any effect on the transaction as a whole. 101
> has no effect on the *request* bytes and 100 has no effect on the

I don't think that a server upgrading to HTTP/2.0 should be sending
100 responses that control the sending of the HTTP/1.1 request.  I
just can't imagine how that would be healthy.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 6 Sep 2013 21:52:27 +0300

> just can't imagine how that would be healthy.

So if server sends 101 and then 100, one direction of connection is
HTTP/1.1 and the other is HTTP/2.0 until the request is completed?

Does the HTTP/2.0 flow control apply? :->

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 12:05:57 -0700

> HTTP/1.1 and the other is HTTP/2.0 until the request is completed?

Presumably, yes.  But we shouldn't allow that.

> Does the HTTP/2.0 flow control apply? :->

Of course not.  The client is speaking 1.1.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Sep 2013 21:12:45 +0200

> Presumably, yes.  But we shouldn't allow that.

In fact not really. The client requests an Upgrade and expects whatever
it sees after the double CRLF following the 101 to be in the upgraded
protocol. So it's not one direction in one version and the other one in
another version, it's one side ready for 2.0 and the other side not yet
aware of this readiness and waiting for the response to come.

Willy

---

From: Osama Mazahir <[email-masked]>
Date: Fri, 6 Sep 2013 23:04:19 +0000

Speaking as the HTTP server stack implementer, the best way, IMHO, is to mandate that:
1 - the server emit the 100 first followed by the 101.
2 - the client emit the entire request in HTTP/1.1 (which is a result of #1)

It is legal for the client to send the entity body without waiting for the 100.  Consequently, if the server were to send the 101 first then the server does not know whether the next set of bytes it receives (i.e. entity body) from the client were sent before or after the client got the 101.  This means the server side parser cannot deterministically parse the request stream.  By sending the 100 first, we guarantee that the client will emit the entity-body in HTTP/1.1.  Then the server sends the 101 and subsequent HTTP/2.0 bytes.  As soon as the server sends the 101, the server knows that the next inbound bytes will be HTTP/2.0 and as soon as the client receives the 101 it knows it can send HTTP/2.0 and that the next inbound bytes will be HTTP/2.0.

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Friday, September 6, 2013 12:13 PM
To: Martin Thomson
Cc: Ilari Liusvaara; Amos Jeffries; Roy T. Fielding; Michael Sweet; Daniel Stenberg; HTTP Working Group
Subject: Re: Expect: + Upgrade: = ...

> Presumably, yes.  But we shouldn't allow that.

In fact not really. The client requests an Upgrade and expects whatever it sees after the double CRLF following the 101 to be in the upgraded protocol. So it's not one direction in one version and the other one in another version, it's one side ready for 2.0 and the other side not yet aware of this readiness and waiting for the response to come.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 07 Sep 2013 15:37:01 +1200

>> There is nothing preventing the server emitting further 100 status frames

1xx. In this specific case we are talking about 100 (or HTTP/2 version 
of that).

> you might get more 1xx status codes, but you won't get 100, because

Why is 100 being prohibited is what I am questioning? I thought it was 
Expect that was being deprecated for transmission in HTTP/2. 
100-continue has other uses far beyond Expect and there seems to be no 
reason not to respond in HTTP/2 format to a HTTP/1 feature sent using 
HTTP/1. The text in Upgrade would seem to require it.

If the server has chosen to switch protocols it need to ensure that the 
new protocol is capable of responding to the earlier request 
appropriately. I

And the arguments I've already put forwared for allowing a 100 frame to 
be sent in HTTP/2 format to ensure the HTTP/1.1 payload gets delivered 
show that the

Going back to the earlier proposal:
"

"

It does not address the original thread starting question: What happens if the new protool is used to send the 100 after the 101. Assuming that the new protocol is capable of that to begin with.
  Does the client see the 101 as a final state and start sending the payload immediately?
  Does it wait for a 100 which the new protocol may be used to deliver slightly later?
  Does it wait for its timeout?

It has become clear in this thread we all disagree on the implementation of that part which will cause interoperation issues. So the text does need to be clearer on that case.
- Retaining the timeout is a no-brainer, but does impose the HTTP/1 blocking problem onto whatever protocol was upgraded to.
- Retaining the payload in HTTP/1 format is agreed (I think).

Also, keep in mind that this will not just be affecting Expect:, but any other similar HTTP/1 feature which relies on a specific 1xx status to trigger some behaviour.

I propose a third paragraph after the above proposals text, stating that a client which uses such features along with Upgrade needs to be able to handle the response required by those features to happen within the new protocol, or not use them at all.

That still leves the problem of what a intermediary gateway should do. It may seem simple for the gateway to send 100 then 101, but when the applicatino places (ncorrect) assumptions that eth 100 comes from the origin server things get tricky.

> just can't imagine how that would be healthy.

How woud it be unhealthy if both protocols support sending the 1xx 
status frame required?

Or rather is it bad enough that we should mandate a gateway to emit 
100-continue on behalf of orign servers N hops away with unknown 
application-layer semantics depending on the Expect being end-to-end?

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 7 Sep 2013 07:18:56 +0200

Hi,

On Fri, Sep 06, 2013 at 11:04:19PM +0000, Osama Mazahir wrote:
> It is legal for the client to send the entity body without waiting for the
> 100.

This is a very good point, I didn't think about it.

> Consequently, if the server were to send the 101 first then the server
> does not know whether the next set of bytes it receives (i.e. entity body)
> from the client were sent before or after the client got the 101.  This means
> the server side parser cannot deterministically parse the request stream.  By
> sending the 100 first, we guarantee that the client will emit the entity-body
> in HTTP/1.1.  Then the server sends the 101 and subsequent HTTP/2.0 bytes.
> As soon as the server sends the 101, the server knows that the next inbound
> bytes will be HTTP/2.0 and as soon as the client receives the 101 it knows it
> can send HTTP/2.0 and that the next inbound bytes will be HTTP/2.0.

I'm perfectly fine with this.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 7 Sep 2013 07:44:57 +0200

Hi Amos,

On Sat, Sep 07, 2013 at 03:37:01PM +1200, Amos Jeffries wrote:
> It does not address the original thread starting question: What happens if 
> the new protool is used to send the 100 after the 101. Assuming that the 
> new protocol is capable of that to begin with.

Osama made a very good point to disallow this case :

  "It is legal for the client to send the entity body without waiting for the 100".

Thus if the protocol allows to switch before getting the bytes, the server
has no way to know whether it's receving an HTTP/2 stream or the HTTP/1
payload body.

> It has become clear in this thread we all disagree on the implementation of 
> that part which will cause interoperation issues.

Initially I was for allowing both cases to coexist but now for me it is
clear that we must not allow 100 to be processed after 101.

> So the text does need to 
> be clearer on that case.
> - Retaining the timeout is a no-brainer, but does impose the HTTP/1 
> blocking problem onto whatever protocol was upgraded to.

So what about this :

   http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-6.2.2

   The server
   MUST generate an Upgrade header field in the response that indicates
-  which protocol(s) will be switched to immediately after the empty
-  line that terminates the 101 response.
+  which protocol(s) will be switched to. The new protocol takes effect
+  on each direction after the end of the current message, which means
+  on the request path immediately after any advertised payload body, and
+  on the response path immediately after the empty line that terminates
+  the 101 response.
+
+  When receiving a 101 status code, a client that was waiting for a 100
+  status code before emitting its payload body must immediately send it
+  in order to complete the protocol switch.
+
+  A client waiting for a 101 status code to upgrade the protocol must still
+  be prepared to handle other 1xx interim responses first before receiving
+  the 101 status code confirming the protocol upgrade.

With that, it makes it clear even for intermediaries what protocol is in
effect on each side and direction.

Comments ?

Willy

---

From: "Peter Occil" <[email-masked]>
Date: Sat, 7 Sep 2013 08:02:05 -0400

"The new protocol takes effect on each direction after the end of the 
current message, which means on the request path immediately after any 
advertised payload body ...."

As far as I can tell, nothing in the current draft disallows the use of 
trailers with the Upgrade header field.

--Peter

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 7 Sep 2013 14:56:14 +0200

> trailers with the Upgrade header field.

Hmmm yes of course, I forgot about them. So "... and/or any trailers if relevant".
I think "the end of the current message" is the important part anyway.

Regards,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Sep 2013 11:28:54 -0700

> I think "the end of the current message" is the important part anyway.

I think that your proposed text (with amendments) is good.  I'd rather
not have to back-specify from HTTP/2.0, so... 1.1 editors/chair?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Sep 2013 13:08:16 +1000

> not have to back-specify from HTTP/2.0, so... 1.1 editors/chair?

I added this as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/497>, and Roy incorporated a proposal; see linked commit.

Cheers,

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Sep 2013 20:40:16 -0700

On Sep 24, 2013 1:08 PM, "Mark Nottingham" <[email-masked]> wrote:
> I added this as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/497>,
and Roy incorporated a proposal; see linked commit.

Cheers. The text covers it well.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 24 Sep 2013 07:10:35 +0200

> Cheers. The text covers it well.

Fine by me as well.

Willy

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 24 Sep 2013 08:55:13 +0200 (CEST)

On Tue, 24 Sep 2013, Mark Nottingham wrote:

> I added this as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/497>, and 
> Roy incorporated a proposal; see linked commit.

Thanks, this adresses the concern I had.

-- 

  / daniel.haxx.se