Subject: Re: END_SEGMENT? (#397)

From: Yutaka Hirano <[email-masked]>
Date: Tue, 1 Jul 2014 22:42:52 +0900

>
> b) A new protocol needs a new application negotiation token.

Does this option mean that all intermediaries should express its support
for the application?

Thanks,

On Tue, Jul 1, 2014 at 3:45 AM, David Krauss <[email-masked]> wrote:

>
> On 2014–07–01, at 2:40 AM, Martin Thomson <[email-masked]>
> wrote:
>
> > On 30 June 2014 11:23, David Krauss <[email-masked]> wrote:
> >>> That's an argument for the new application negotiation token.
> >>
> >> Such a proxy should only be put in a place where no negotiation is
> necessary. Bailing out at any END_SEGMENT would be acceptable then.
> >
> > There's an obvious counterargument to that one...
> >
> > That's fine, but if you want to operate sans-standard, then you can
> > add your own END_SEGMENT.
>
> Should be explicitly prohibited.
>
> > I really don't care either way here.  I'm just enumerating the
> > options, and noting that what is currently specified isn't
> > particularly well-supported.  Our responsibility is to either more
> > clearly define it, or remove it.
>
> This I agree with. Actually the same goes for mid-stream headers.
>
> I gave up on the earlier thread, but I still think that END_SEGMENT should
> be explicitly defined as a compressed representation of an empty header
> set, to be processed after the current frame.
>
> This puts HTTP/1.1 intermediary support exactly on par. No worries about
> semantics, no hook for application designers to work their twisted magic.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Jul 2014 11:18:11 -0700

On 1 July 2014 06:42, Yutaka Hirano <[email-masked]> wrote:
> Does this option mean that all intermediaries should express its support for
> the application?

That would be a policy decision.  But it does mean that the proxy
would be required to express support prior to using the feature.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jul 2014 15:02:22 +1000

<https://github.com/http2/http2-spec/issues/537>

On 1 Jul 2014, at 4:40 am, Martin Thomson <[email-masked]> wrote:

>> Such a proxy should only be put in a place where no negotiation is necessary. Bailing out at any END_SEGMENT would be acceptable then.
> 

Agreed.

It sounds like we're leaning towards removing it - can people live with that?

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

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 2 Jul 2014 14:28:59 +0900

It is OK for me if an "explicit acknowledgement" (including proxies) mechanism
for extensions is specified in the HTTP/2 spec. Otherwise, not.
IIUC such mechanism is not specified, right? Is there any discussion?

Thanks,

---

From: David Krauss <[email-masked]>
Date: Wed, 2 Jul 2014 13:57:48 +0800

> It sounds like we're leaning towards removing it - can people live with that?

As I noted in the other thread and on GitHub, segments are redundant with midstream headers. Both require data not to be coalesced across a boundary, and weakly suggest that intermediaries should flush. Neither work over HTTP/1.1.

I have no complaint about removal, but “deprecation in favor” might be better terminology.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 1 Jul 2014 23:12:22 -0700

Segments are not redundant with midstream headers.
Headers potentially have semantic meaning, even when 'empty'.

For my part, I still see that END_SEGMENT or something similar provides for
interesting characteristics for HTTP2->1 gateways in allowing chunks to be
reproduced (and we know that there are issues there) as well as allowing
the coalescing/tunneling of protocols such as WS onto the connection,
making them more viable.

-=R

On Tue, Jul 1, 2014 at 10:57 PM, David Krauss <[email-masked]> wrote:

> As I noted in the other thread and on GitHub, segments are redundant with
> midstream headers. Both require data not to be coalesced across a boundary,
> and weakly suggest that intermediaries should flush. Neither work over
> HTTP/1.1.
>

---

From: David Krauss <[email-masked]>
Date: Wed, 2 Jul 2014 14:20:50 +0800

On 2014–07–02, at 2:12 PM, Roberto Peon <[email-masked]> wrote:

> Headers potentially have semantic meaning, even when 'empty’.

There is no other difference. (I think I accounted for that, the last couple times I explained this.)

If segments were gone, applications would simply use headers to express the same thing. Compatibility is not currently an issue. (Semantic complexity is an issue, but not in a good way. I don’t think the potential for application discrimination is a counterargument at all to Mark’s original question.)

> For my part, I still see that END_SEGMENT or something similar provides for interesting characteristics for HTTP2->1 gateways in allowing chunks to be reproduced (and we know that there are issues there) as well as allowing the coalescing/tunneling of protocols such as WS onto the connection, making them more viable.

Could the same be done with an empty midstream header set? It must be relayed by HTTP/2 intermediaries, but may be stripped when translating to HTTP/1.1.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 06:36:02 +0000

>the coalescing/tunneling of protocols such as WS onto the connection,

What issues would those be and where do we know them to exist ?

Are they hacks to be discouraged or architecture to be respected ?

I have yet to hear about any issues with Varnish making totally random
(seen form the applications point of view) decisions about chunk sizes.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 1 Jul 2014 23:44:02 -0700

You're welcome to ask Twitter about it.

As I recall it, certain client implementations fail when chunks are not
done in a particular way, despite the fact that the spec says otherwise.
In my experience, supporting old hardware-based implementations requires
annoying hacks such as this when one really cares about compatibility.
-=R

On Tue, Jul 1, 2014 at 11:36 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CAP+FsNdwizDUMCunLGhftkfgbJfstvAG3Ux8qtpHuL=
> [email-masked]>, Roberto Peon writes:
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 1 Jul 2014 23:52:19 -0700

On Tue, Jul 1, 2014 at 11:20 PM, David Krauss <[email-masked]> wrote:

> If segments were gone, applications would simply use headers to express
> the same thing. Compatibility is not currently an issue. (Semantic
> complexity is an issue, but not in a good way. I don’t think the potential
> for application discrimination is a counterargument at all to Mark’s
> original question.)
>

That is a work-around and not an equivalent. It precludes the expression of
empty metadata, requires more bytes, adds complexity and potentially
requires modification of the compressor state, likely rendering the
compressor less effective.

There are two use-cases for it, as explained before.
Proxies/gateways which interpret in the session layer (e.g. loadbalancers)
should not.

> > For my part, I still see that END_SEGMENT or something similar provides
> for interesting characteristics for HTTP2->1 gateways in allowing chunks to
> be reproduced (and we know that there are issues there) as well as allowing
> Could the same be done with an empty midstream header set? It must be
> relayed by HTTP/2 intermediaries, but may be stripped when translating to
> HTTP/1.1.
>
>
All the arguments about not passing END_SEGMENT exist for any midstream
HEADER, so to me the difference isn't compelling.
-=R

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 2 Jul 2014 09:50:38 +0200

As I see it, END_SEGMENT is good semantics that does belong in a general
framing layer which is designed to carry protocols such as HTTP, Websocket
etc.

However, because we have conflated the protocol semantics with the framing
layer, for HTTP at least we are able to use frame type (eg HEADERs) in
place of END_SEGMENT to define semantic boundaries for proxies and
intermediaries.

So looking at this from an HTTP perspective only, they are not required and
we could live without them.   But I truly believe that our future is
multi-protocol and eventually we will learn that conflating the HTTP layer
with framing was a bad idea, and that we will eventually remove frame types
like HEADER, PUSH_PROMISE and CONTINUATION, and be left with only DATA
frames with segment semantics - which are more than sufficient to send
HTTP, Websocket, and other protocol semantics.

So my preference would be to keep END_SEGMENT and drop the conflation. But
as that is not going to happen, unless websocket is going to use
END_SEGMENT in the near future, then I guess it is best to drop it as
unused.

Note that I understand that websocket will be an extension, and thus it is
able to add END_SEGMENT semantics if needed - but this will need all
intermediaries to support the extension.  If we had not conflated the
layers, then many intermediaries would have been able to handle such
extensions without explicitly knowing about them - oh well, that's just me
crying over spilt milk.

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 2 Jul 2014 15:43:11 +0000

Explicit acknowledgements are required for extensions which change semantics, which would include (re-)defining a flag on the DATA frame.  On the other hand, without acknowledgement, an END_SEGMENT frame could be defined with no payload and would be discarded by implementations that don't understand it.

Sent from Windows Mail

From: Yutaka Hirano<mailto:[email-masked]>
Sent: ?Tuesday?, ?July? ?1?, ?2014 ?10?:?32? ?PM
To: Mark Nottingham<mailto:[email-masked]>
Cc: HTTP Working Group<mailto:[email-masked]>, Martin Thomson<mailto:[email-masked]>

It is OK for me if an "explicit acknowledgement" (including proxies) mechanism for extensions is specified in the HTTP/2 spec. Otherwise, not.
IIUC such mechanism is not specified, right? Is there any discussion?

Thanks,

On Wed, Jul 2, 2014 at 2:02 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
<https://github.com/http2/http2-spec/issues/537>

On 1 Jul 2014, at 4:40 am, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

> On 30 June 2014 11:23, David Krauss <[email-masked]<mailto:[email-masked]>> wrote:

Agreed.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Jul 2014 15:30:02 +1000

It sounds like we've converged on getting rid of END_SEGMENT. I've marked it as editor-ready.

Regards,

On 3 Jul 2014, at 1:43 am, Mike Bishop <[email-masked]> wrote:

> Explicit acknowledgements are required for extensions which change semantics, which would include (re-)defining a flag on the DATA frame.  On the other hand, without acknowledgement, an END_SEGMENT frame could be defined with no payload and would be discarded by implementations that don’t understand it.
> 
> Sent from Windows Mail
> 
> From: Yutaka Hirano
> Sent: ‎Tuesday‎, ‎July‎ ‎1‎, ‎2014 ‎10‎:‎32‎ ‎PM
> To: Mark Nottingham
> Cc: HTTP Working Group, Martin Thomson
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 10:10:07 -0700

> It sounds like we've converged on getting rid of END_SEGMENT. I've marked it as editor-ready.

Since we're removing affordances for websockets, can I handle #557 at
the same time.  Not by adding METADATA, but by removing random,
semantic-free HEADERS frames.

---

From: Nicholas Hurley <[email-masked]>
Date: Tue, 15 Jul 2014 14:20:28 -0700

> semantic-free HEADERS frames.

I'd be OK with this. No websocket affordances, no non-semantic HEADERS, no
problem!

Seriously, though, there's no particular need now to send HEADERS frames at
random points during a stream's lifecycle (after the initial
HEADER/CONTINUATION block, of course). Why allow it at all? Make it a
GOAWAY-able (or at least RST_STREAM-able) offense.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 14:27:17 -0700

> GOAWAY-able (or at least RST_STREAM-able) offense.

Would that make it easier for you to ensure that you correctly process streams?

---

From: David Krauss <[email-masked]>
Date: Wed, 16 Jul 2014 07:21:38 +0800

What happened to WebSockets? Was a decision made off-list?

Some means of flushing a stream is invaluable to interactive applications. A policy of one stream per request eats server (and intermediary) resources, and exhausts stream iDs.

Don’t tell me that the traditional web isn’t interactive. Just because WebSockets aren’t yet widely deployed, doesn’t mean it isn’t the direction things are headed. HTTP/2 should be accelerating that process.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 16:38:14 -0700

> What happened to WebSockets? Was a decision made off-list?

We have never had WebSockets support in HTTP/2.  We have promised to
develop something, but have expressly deferred work on that until this
is done.

I removed the interstitial HEADERS because they comprise the same
feature in my mind and I'd forgotten that the patch I'd prepared had
that change as well.  I can un-remove if we have consensus to retain
them.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 16 Jul 2014 09:37:54 +1000

Because h2 is being designed as http only (as it is chartered to do), then
the only way that other semantics are going to be able to transit the h2
web is by making themselves look like http semantic!    Otherwise they will
be back at some 85% level because of intermediaries that don't accept
extensions and/or can only handle http semantic.

This is precisely the kind of protocol misuse the charter also asks us to
fix.

charter fail I think!

cheers

PS. if we fix HOL blocking, then http over h2 is a much more flexible
semantic for carrying websocket like semantic as things like long polling
will work much better.   But it will be very hard for a client to work out
the best transport to use as it does not really know if h1 or h2 will be
used or if it is better to try websocket.

On 16 July 2014 09:21, David Krauss <[email-masked]> wrote:

> Some means of flushing a stream is invaluable to interactive applications.
> A policy of one stream per request eats server (and intermediary)
> resources, and exhausts stream iDs.
>
> Don’t tell me that the traditional web isn’t interactive. Just because
> WebSockets aren’t yet widely deployed, doesn’t mean it isn’t the direction
> things are headed. HTTP/2 should be accelerating that process.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Jul 2014 16:46:04 -0700

> used or if it is better to try websocket.

You can try to start h2 and then upgrade to websockets if the ALPN
negotiation selects http1.1.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 16 Jul 2014 09:57:30 +1000

> negotiation selects http1.1.

Currently this kind if decision is made above the browser in javascript
libraries that have to decide if they are going to use websocket or long
polling.  If they use long polling, for h1 they have to be aware of
connection limits and currently some assume 2, while others have been
updated to 6.  A much higher connection==stream limit will need to be
applied if long polling over h2.     But these frameworks don't have the
ability to take part in h2/upgrade negotiations and any knowledge they get
about protocol versions will be late.  They probably don't have access to
max stream settings, so will be guessing again.

Now if h2 had supported websocket semantics from day 1, then these
libraries could have just handed over the messages to the browser and it
would be up to the browser to work out the best way to transport.

Anyway.... I've made my point (several times) that I think it was a mistake
for the charter to not support all the current web semantics.  I guess that
horse bolted a long time ago.

cheers

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 16 Jul 2014 10:51:25 +0900

I'm a bit behind, can you tell me what you mean by "semantic-free" HEADERS?
It the current stance for extensions (such as WebSocket) "Do not abuse HTTP
related frames. Instead, define and use extension-specific frames"?

On Wed, Jul 16, 2014 at 8:57 AM, Greg Wilkins <[email-masked]> wrote:

> Anyway.... I've made my point (several times) that I think it was a
> mistake for the charter to not support all the current web semantics.  I
> guess that horse bolted a long time ago.
>
> cheers
>
>
>
> --

---

From: Roberto Peon <[email-masked]>
Date: Tue, 15 Jul 2014 20:15:05 -0700

I'd say that the current stance is that anything which isn't part of the
past set of usecases for http will not be considered for h2.

This is disappointing, but there it is. It is difficult to do anything
forward looking in committee, regardless of its venue or the talent of its
members.
On Jul 15, 2014 6:55 PM, "Yutaka Hirano" <[email-masked]> wrote:

> It the current stance for extensions (such as WebSocket) "Do not abuse
> HTTP related frames. Instead, define and use extension-specific frames"?
>
>
>
>

---

From: Erik Nygren <[email-masked]>
Date: Wed, 16 Jul 2014 17:53:02 -0400

I worry we'll regret losing segments and mid-stream HEADERS (or METADATA or
the like).

The hop-by-hop HTTP use-cases (eg, in ICAP and for data integrity
protection) seem like one where we can re-introduce them fine with
extensions.  However the end-to-end cases (WebSockets) seem like they will
be harder to get intermediates to support well in the long-term if we don't
define them now.

Similarly, when WebSockets and the like do implement something, the
implementations
would presumably be much more consistent if the framing layer has a clearly
defined
mechanism for supporting them so that each one of them doesn't result in a
new
slightly different frame type with slightly different formatting and
semantics.

       Erik

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jul 2014 15:39:10 -0700

> slightly different frame type with slightly different formatting and

Would you prefer an intermediary who knows what you are doing and has
provided a positive indication of that, or an intermediary who is
merely unwittingly passing your packets?

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 17 Jul 2014 10:21:40 +1000

On 17 July 2014 08:39, Martin Thomson <[email-masked]> wrote:

> provided a positive indication of that,
>

In a perfect world the client, intermediaries and server would all embrace
in a group hug to celebrate their acceptance of the same semantics

> or an intermediary who is

Failing living in a perfect world, then unwittingly passing on packets is
possibly better than discarding them.

However, I think the horse has bolted on this one and there are lots of
other impediments to intermediaries being able to mindlessly forward new
protocols.    So I am actually OK with removing segments on the basis that
generalising without use-cases is bad.

In some parallel universe we are chartered to make h2 carry both http and
websocket semantic and group hugs are more frequent in that dimension.

cheers

PS> I really fear that websockets over h2 is going to end up with a
long-polling style request stream that will carry push promises for each
message from server to client, just so that the traffic will look like http
and pass through http only intermediaries.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jul 2014 14:17:14 +1000

>> What happened to WebSockets? Was a decision made off-list?

We've talked about WS many, many times, both in the interims and on the list. Most recently, this was in June; see the issue for the history <https://github.com/http2/http2-spec/issues/386>. 

> develop something, but have expressly deferred work on that until this

Er, when did we make such a promise?

Our charter only requires us to "[coordinate with] The HYBI Working Group, regarding the possible future extension of HTTP/2.0 to carry WebSockets semantics." The HYBI WG chairs are fully aware of our actions here (since they were both in the room when these conversations took place).

We might decide to do something in the future, but we're not committed to any particular action.

Cheers,

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 17 Jul 2014 14:35:44 +0900

Thanks, I understand.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 09:25:31 -0700

> We might decide to do something in the future, but we're not committed to any particular action.

Mea culpa.  That's right.