Subject: CONTINUATION was: #540: "jumbo" frames

From: <[email-masked]>
Date: Thu, 26 Jun 2014 11:56:42 +0000

On Thursday,26 June 2014 00:01, [email-masked]<mailto:[email-masked]> wrote (emphasis added):

> Continuations are jumbo frames!  They are just really bad jumbo frames that only apply to headers,

> can't be efficiently handled and don't have a mechanism for end points to pre declare max acceptable

> sizes.   General jumbo frames would handle the headers use-case, but also provide a solution for those

> who need efficient large data.

> h2 should either just support general jumbo frames for both headers and data or no jumbo frames for either.

> By supporting jumbo headers, but not jumbo data, a double standard is being applied.  ...

My thoughts exactly.

Looking back at Richard’s data [1][2] for request and response header sizes…

only 0.02% of requests have headers > 16KB

only 0.006% of responses have headers > 16KB

Who exactly are all these people so interested in header sets > 16KB that we need to have so much special effort in the spec (CONTINUATION) to support such a miniscule number of requests?

Seriously, who?  I looked back through the mailing list archives.  All I could find was the discussion for how to implement CONTINUATION, but I couldn’t find a discussion about the motivation.

I’m ok with relegating jumbo frames to the world of h2 extensions (although Willy might disagree), but if so, CONTINUATION should also get ripped out.

Those who need headers >16KB can use the jumbo frame extension, or if they really love CONTINUATION they can put it in another h2 extension.

Ship it without CONTINUATION.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0905.html

[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1018.html

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Jun 2014 17:49:01 +0000

One example is Kerberos tickets, which can be up to 64KB (after Base64 encoding).  While they're a tiny fraction of requests on the Internet, they exist in HTTP/1.1.

Sent from Windows Mail

From: [email-masked]<mailto:[email-masked]>
Sent: ?Thursday?, ?June? ?26?, ?2014 ?5?:?01? ?AM
To: Greg Wilkins<mailto:[email-masked]>, HTTP Working Group<mailto:[email-masked]>

My thoughts exactly.

Looking back at Richard's data [1][2] for request and response header sizes...

Seriously, who?  I looked back through the mailing list archives.  All I could find was the discussion for how to implement CONTINUATION, but I couldn't find a discussion about the motivation.

I'm ok with relegating jumbo frames to the world of h2 extensions (although Willy might disagree), but if so, CONTINUATION should also get ripped out.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 26 Jun 2014 21:37:43 +0200

On 26 June 2014 19:49, Mike Bishop <[email-masked]> wrote:

> One example is Kerberos tickets, which can be up to 64KB (after Base64
> encoding).  While they’re a tiny fraction of requests on the Internet, they
> exist in HTTP/1.1.

As many parts of http infrastructure have a defacto 8kB header limit, then
any traffic with 64KB headers is only going to work with prior agreement
between client, intermediaries and servers.   Sounds like a negotiated
extension to me!

With the current h2 draft, many implementation will probably not support
continuations at all, so such kerberos tickets are likely to receive a 413
response unless there is prior negotiation along the path.   There is not
even a mechanism to determine the max size supported by a path, only
rejection if something is too big.  Surely a negotiated big header
extension would be better than this uncertainty?

regards

cheers

-- 
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: Martin Thomson <[email-masked]>
Date: Thu, 26 Jun 2014 12:50:26 -0700

On 26 June 2014 12:37, Greg Wilkins <[email-masked]> wrote:
> rejection if something is too big.  Surely a negotiated big header extension
> would be better than this uncertainty?

Didn't I already explain that it's basically impossible to remove this
uncertainty?

---

From: Jason Greene <[email-masked]>
Date: Thu, 26 Jun 2014 14:53:06 -0500

On Jun 26, 2014, at 2:37 PM, Greg Wilkins <[email-masked]> wrote:

> One example is Kerberos tickets, which can be up to 64KB (after Base64 encoding).  While they’re a tiny fraction of requests on the Internet, they exist in HTTP/1.1.
> 
> As many parts of http infrastructure have a defacto 8kB header limit, then any traffic with 64KB headers is only going to work with prior agreement between client, intermediaries and servers.   Sounds like a negotiated extension to me
> 
> With the current h2 draft, many implementation will probably not support continuations at all, so such kerberos tickets are likely to receive a 413 response unless there is prior negotiation along the path.   There is not even a mechanism to determine the max size supported by a path, only rejection if something is too big.  Surely a negotiated big header extension would be better than this uncertainty?

That’s a gerat point. From a proxy perspective CONTIUATION, as it is currently defined, is flat out evil. If you attempt to coalesce multiple connections (be it http/1.1, spdy, or http/2), you ideally want to multiplex it all, and perhaps even forward it, which will work great up until the point that one client out of all of the aggregated clients decides to misuse CONTINUATION. After that point chaos reigns, and connections start dropping everywhere.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 26 Jun 2014 21:55:19 +0200

> Didn't I already explain that it's basically impossible to remove this

Why?  If a path negotiates a
please-transport-my-stupidly-large-kerberos-ticket extension, then surely
there should some reasonable certainty that such a ticket can be
transported over that path.

For the purposes of this conversation, I don't care how the extension sends
it, but if asked I would suggest in flow controlled data frames.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 26 Jun 2014 22:01:11 +0200

To double up on my reply.... the uncertainly we currently have is only as a
result of applications trying to stick arbitrarily large data into the
transport meta-data channel.  Because there are real limitations on how
large transport meta-data channels can be all along a http path, such
applications are going to be hit with limits - many of which are
undisclosed and undiscoverable.

So the solution to this uncertainly is to stop encouraging applications to
put arbitrary large data into the transport meta-data channel.   The
current draft actually gives and incentive to do so!

We should be giving applications alternate channels for their meta-data.
Perhaps that is "stateless multiplexable continuations #541"? Or something
else.    Whatever, it is certainly something that is achievable and I think
it is crazy to enforce h2 to copy this drastic mistake of h1!

On 26 June 2014 21:55, Greg Wilkins <[email-masked]> wrote:

> For the purposes of this conversation, I don't care how the extension
> sends it, but if asked I would suggest in flow controlled data frames.
>
> regards
>
>
>
>
> --

---

From: Roberto Peon <[email-masked]>
Date: Thu, 26 Jun 2014 14:41:19 -0700

Today the use of CONTINUATION does not imply header block > 16k.
So be careful what you're considering "evil", and why :)

-=R

On Thu, Jun 26, 2014 at 1:01 PM, Greg Wilkins <[email-masked]> wrote:

> To double up on my reply.... the uncertainly we currently have is only as
> a result of applications trying to stick arbitrarily large data into the

---

From: <[email-masked]>
Date: Thu, 26 Jun 2014 22:41:20 +0000

> So be careful what you're considering "evil", and why :)

The point is CONTINUATIONS _can_ be used to be "evil" and as Greg points out, there is an incentive to use them that way.

Please share your use case for CONTINUATION when the header block is not >16KB.

So far all we have is Kerberos tickets. Was Kerberos the primary motivation for CONTINUATION & infinite headers?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jun 2014 15:56:47 -0700

> Please share your use case for CONTINUATION when the header block is not >16KB.

This would be a great line of argument if we were creating a new protocol.

Sadly we are not.  We are responsible here for accommodating the uses
of HTTP that exist.  We're not dictators, we're curators.

As such, we can't unilaterally impose restrictions like this.
Historically, this working group has been extremely conservative when
it comes to marking HTTP features as deprecated and even more
conservative when actually removing those features, as was done for a
very small handful of features in the latest HTTP/1.1 rewrite.  Each
time, a large body of evidence was required to justify even
deprecation.

The same applies here.  We're chartered to define a protocol that can
carry HTTP.  We already have evidence that >16K of headers is
sometimes used.  And that is enough reason to provide support.
Period.

---

From: Jesse McConnell <[email-masked]>
Date: Thu, 26 Jun 2014 18:13:15 -0500

> sometimes used.  And that is enough reason to provide support.

Which is fine, but why not support that oft cited questionable need
through an extension as opposed to a seemingly largely reviled
CONTINUATION mechanism?

cheers,
jesse

---

From: <[email-masked]>
Date: Thu, 26 Jun 2014 23:33:57 +0000

On 27 June 2014 00:56, [email-masked] wrote:
> We are responsible here for accommodating the uses
> [snip]

Nobody is arguing against support.  If jumbo data frames should be an extension, so should jumbo header frames (i.e. CONTINUATION).

Following your line of logic that "we're chartered to define a protocol that can carry HTTP", then you can't unilaterally get rid of *transfer-encoding*, I can provide ample evidence that t-e is, in your words, "sometimes used".

> Period.

That sounds exactly like what a dictator would say.  Or my mom when I was a kid (same thing?).

---

From: Roberto Peon <[email-masked]>
Date: Thu, 26 Jun 2014 17:26:24 -0700

I mentioned this previously, but large set-cookie headers designed to clear
out cookies.

The primary motivation was backward compatibility, as we saw when launching
SPDY that assumptions about max header size were often invalid. I've seen
complaints that URL are capped at Xk before, for instance.

I'll say again that it seems like folks are reacting not to CONTINUATIONS,
but to the fact that headers have unlimited length.

Continuations could be used with small header sizes, and should not be
confused with the size/anti-backwards compatibility arguments
-=R
On Jun 26, 2014 3:41 PM, <[email-masked]> wrote:

> The point is CONTINUATIONS _can_ be used to be "evil" and as Greg points
> out, there is an incentive to use them that way.
>
> Please share your use case for CONTINUATION when the header block is not
> >16KB.
>
> So far all we have is Kerberos tickets. Was Kerberos the primary
> motivation for CONTINUATION & infinite headers?
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jun 2014 19:22:25 -0700

> Nobody is arguing against support.  If jumbo data frames should be an extension, so should jumbo header frames (i.e. CONTINUATION).

There's a fairly straightforward calculus.

Can HTTP do X -> HTTP/2 MUST do X.

So, can HTTP/2 carry arbitrary amounts of data: yes.  The debate there
is about efficiency.  That's very different.

It's different with headers.  If we cap header size, then it becomes
literally impossible to make some requests.

> you can't unilaterally get rid of *transfer-encoding*, I can provide ample evidence that t-e is, in your words, "sometimes used".

I'd rather not re-open that debate, but I think that your concern with
transfer-encoding fixates on the means and not the capability.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Jun 2014 06:38:19 +0200

> confused with the size/anti-backwards compatibility arguments

That's an interesting point. So that means that if some dirty client or
server finds it easier to send headers in small chunks with CONTINUATION,
everyone has to implement it or risks to break. However, if we specify
that CONTINUATION may only be used for header sizes that do not fit into
one frame, then I think that a number of us will simply reject them and
this will incite implementations to avoid abusing headers unless they're
working in a very well controlled environment (eg: just like today with
H1 where people trying to exceed 8kB over the internet have to be very
careful).

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 27 Jun 2014 06:04:48 +0000

In message <[email-masked]>
>of HTTP that exist.  We're not dictators, we're curators.

"the uses" or only "some of the uses" ?

Is high performance load-balancing in the set of uses "we are
responsible for accomodating" ?

>As such, we can't unilaterally impose restrictions like this.

My proposal for jumboframes contain no restrictions that differ from
restrictions in HTTP/1.

-- 
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: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 27 Jun 2014 06:07:59 +0000

In message <[email-masked]>

>confused with the size/anti-backwards compatibility arguments

But why would you do that ?

When and where are multiple frames in a design which breaks
any kind of sensible protocol-layering better than a cleanly layered
format where framing has simple and easy to implement rules ?

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Jun 2014 18:29:53 +1200

On 27/06/2014 2:22 p.m., Martin Thomson wrote:
> On 26 June 2014 16:33, K.Morgan wrote:

HTTP can produce a valid response for:
## telnet example.com 80\n
. *\n

HTTP/2 already cannot even make the request.

> literally impossible to make some requests.

HTTP/1.1 header size is capped at 64KB by Squid. Other implementators
previously stated 4KB, 8KB and 16KB caps. What is new?

Ability to announce and negotiate a size will be added benefit for
HTTP/2 if accepted.

> transfer-encoding fixates on the means and not the capability.

Whereas retaining CONTINUATION and rejecting jumbo-HEADER extension is
not fixating on one means ?

Something smells fishy there.

Amos

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 27 Jun 2014 08:55:31 +0200

> So be careful what you're considering "evil", and why :)

Roberto,

we totally understand that continuations can be used to send small
headers.  But we are not implementing them because we think that they have
no reason to exist and that the vanishingly small number of users that
would like large meta data should not use http headers as a transport.

So we are attempting to use what ever market influence we have to
discourage other end points from implementing this part of the spec -
because as you may have noticed - we think such an ugly unmotivated
mechanism does not belongs anywhere near the specification.

We are prepared to spend extra resources on each connection in order to
gain the benefits of h2.  But we are drawing a line at continuations and we
are just saying NO period. We will not support them and clients that wish
to use them will just have to be content with failing when used against
jetty servers and other implementations that take a similar position.

If we ever do implement continuations, it will NOT because some clients
might want to send small headers in many tiny frames.  Those clients can go
jump!

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 27 Jun 2014 09:06:33 +0200

> sometimes used.  And that is enough reason to provide support.

Martin,

you have tried to make that argument before, but it failed to convince
before and fails now.  The charter says:

There is emerging implementation experience and interest in a protocol that
retains the semantics of HTTP without the legacy of HTTP/1.x message
framing and syntax, which have been identified as hampering performance and
encouraging misuse of the underlying transport.

So if 64KB header fields may not be entirely misuse, they are certainly
hampering performance and encouraging others to misuse headers.

Further, HTTP semantics allows for a limit on header size.  There have
been technical proposal put here (ie jumbo frames) that would allow an
arbitrary large header limit to be configured and accepted, just as it must
be specifically configured in HTTP/1 implementations today.

Basically it is a strawman to say that the arguments against continuations
are == with those saying that we should not support large meta data.  We
are speaking against continuations and have proposed other mechanisms to
support large headers.

regards

---

From: David Krauss <[email-masked]>
Date: Fri, 27 Jun 2014 15:09:46 +0800

> Ability to announce and negotiate a size will be added benefit for

+1. Ignoring literally 99.98% of usage (add more 9’s for the 64K limit) is not only a mistake, it’s against the rules of any sane governing body.

Has anyone contacted the Kerberos guys? I know nothing about security but it makes sense that an authentication protocol wouldn’t worry about proxyability. Without proxies to worry about, the client can be sure that headers sent by HTTP/1 will only be received as HTTP/1, and authentication sent via HTTP/2 will only be received by a server expecting it. It becomes a non-issue.

RFC 4559 appears to cover the culprit and appears to suggest that it is MSIE. Perhaps a Microsoft rep on this list can find out whether HTTP/2 support for SPNEGO Kerberos will be needed?

---

From: Cory Benfield <[email-masked]>
Date: Fri, 27 Jun 2014 09:05:20 +0100

On 27 June 2014 07:55, Greg Wilkins <[email-masked]> wrote:
> So we are attempting to use what ever market influence we have to discourage
> other end points from implementing this part of the spec - because as you
> may have noticed - we think such an ugly unmotivated mechanism does not
> belongs anywhere near the specification.
>
> We are prepared to spend extra resources on each connection in order to gain
> the benefits of h2.  But we are drawing a line at continuations and we are
> just saying NO period. We will not support them and clients that wish to use
> them will just have to be content with failing when used against jetty
> servers and other implementations that take a similar position.

This is almost certain to be successful.

Either an extension will be implemented that allows negotiation of
CONTINUATION use to detect intermediaries like Jetty that don't accept
them or many clients will simply stop emitting them. Hyper doesn't,
and based on the skeptical reactions from the intermediary providers
in this thread I'm not incentivised to add support for them. All that
will happen is that I'll be inundated with bug reports that tell me
that Hyper doesn't work with Jetty, and I guarantee that my response
of "this is technically Jetty's responsibility" will not go down well.

Interop is more important to me than the moral high ground of
spec-compliance. I'd be quite happy for this WG to postpone WGLC to
come up with a new solution that addresses the concerns of the
intermediaries. As for the proposed alternative approaches:

I'm happy on an implementation level with jumbo frames, either as a
HEADERS-only property or more generally. I appreciate that there's a
concern around using large frames for DATA because of how that affects
muxing, so I'm happy to limit the jumbo frames to HEADERS only.
Negotiation around this property allows for nice fallback behaviours,
where talking directly to endpoints allows use of large header sets,
while intermediaries can push responsibility for large header blocks
onto clients.

I'm less delighted about muxable (i.e. HPACK-free) CONTINUATION
frames, though they might be a better middle-ground solution.
Implementing them intelligently is a bit awkward and requires a
substantial amount of care from the emitting party. It also lays traps
for the unwary such that a single large HTTP header can affect the
compressibility of several following requests. Careful language in the
RFC might be able to get around this point.

I wouldn't push back on either of those two proposals: I have no
specific technical objections to either. I do see some technical
problems with jumbo DATA frames, but if they're negotiated then some
well-chosen language in the RFC suggesting 16kB frame sizes might be
enough. It provides the option to use jumbo DATA frames and warns
about the potential footgun.

---

From: Simone Bordet <[email-masked]>
Date: Fri, 27 Jun 2014 11:36:40 +0200

Hi,

> sometimes used.  And that is enough reason to provide support.

So there is working code or promised code that will not support
CONTINUATIONS are they are defined now.
FWIW, the Jetty implementation for web browsing is complete, and we
would have already put it out in the wild if browsers did not have
fatal bugs (crashes) that are being addressed as we speak.
It does not support CONTINUATIONS.

There is large majority of the people intervening in this thread that
is against CONTINUATIONS are they are defined now, and I am one of
them.

I read this as rough consensus and working code to *not* support
CONTINUATIONS are they are defined now.

I am wondering what is the exact reason the editors do not want to go
the direction the expert group suggests ?
What it is needed to have this happen ?

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 27 Jun 2014 09:57:26 +0000

In message <[email-masked]>

>is against CONTINUATIONS are they are defined now, and I am one of

Count Varnish as one of these.

---

From: Simone Bordet <[email-masked]>
Date: Fri, 27 Jun 2014 13:38:06 +0200

Mark,

thanks for your answers, as usual very informative and helpful in
summarizing what happened in the past.

On Fri, Jun 27, 2014 at 12:53 PM, Mark Nottingham <[email-masked]> wrote:
> It’s great that Jetty is implementing now — welcome! — but characterising your objections plus that of other folks who haven’t implemented as an expert group vs. the editors’ whims is hugely disrespectful of the nearly 20 other implementations that have spent nearly two years working on this, not to mention the effort of the editors.
>

I did not mean to be disrespectful, I am sorry if it sounded so.

> At the risk of repeating myself — most of the implementers are currently being quiet, both because they’re busy getting -13 up to scratch, and frankly I suspect that they don’t want to re-hash the discussion yet again, after doing it for two years (and sometimes more). While this is new to you, it’s well-worn territory for most of the WG, and this is not a random decision by the editors.
>
> As part of the next implementation draft and WGLC, we will assess how well CONTINUATION is implemented, and any problems that it brings. If it's found lacking, we’ll discuss alternatives. At this moment, though, we’re not in a place where we’re going to abandon a feature or re-engineer the protocol without cause; so far CONTINUATION has *not* come up as a problem in the substantial body of running code that we have.
>
> Having said all of that, I’d very much like to hear from other implementers what the current status of their CONTINUATION support is, and what testing plans they have for it.

I find strange that the debate that sparked recently about
CONTINUATION leaves those who like them so silent.
I as well would like to hear why others think CONTINUATION as
currently defined is better than what recently proposed, but I guess
if they did not show up recently they probably won't.

Just in case it happens, you would interpret total silence from those
who currently like/implemented CONTINUATION as it is defined now as a
validation of the protocol as is, so that any alternative proposal
about CONTINUATION to be shipped before last call would be rejected ?

Thanks !

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Jun 2014 20:53:37 +1000

Simone,

> What it is needed to have this happen ?

Hold on there.

Thanks,

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

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 27 Jun 2014 21:26:24 +0900

On Fri, Jun 27, 2014 at 7:53 PM, Mark Nottingham <[email-masked]> wrote:

> It’s great that Jetty is implementing now — welcome! — but characterising
> your objections plus that of other folks who haven’t implemented as an
> expert group vs. the editors’ whims is hugely disrespectful of the nearly
> 20 other implementations that have spent nearly two years working on this,
> not to mention the effort of the editors.
>
> At the risk of repeating myself — most of the implementers are currently
> being quiet, both because they’re busy getting -13 up to scratch, and
> frankly I suspect that they don’t want to re-hash the discussion yet again,
> after doing it for two years (and sometimes more). While this is new to
> you, it’s well-worn territory for most of the WG, and this is not a random
> decision by the editors.
>
> As part of the next implementation draft and WGLC, we will assess how well
> CONTINUATION is implemented, and any problems that it brings. If it's found
> lacking, we’ll discuss alternatives. At this moment, though, we’re not in a
> place where we’re going to abandon a feature or re-engineer the protocol
> without cause; so far CONTINUATION has *not* come up as a problem in the
> substantial body of running code that we have.
>
> Having said all of that, I’d very much like to hear from other
> implementers what the current status of their CONTINUATION support is, and
> what testing plans they have for it.
>
>
​nghttp2 implements CONTINUATION frame.​  Since curl and mruby-http2 use
nghttp2 as HTTP/2 backend, they also support the feature as well.
nghttp command line client included in nghttp2 has convenient option namely
--continuation to send large headers with CONTINUATION to server for
testing purpose.

​Recently I wrote a patch to upgrade wireshark dissector to h2-13, and
found that it also supports CONTINUATION.  It successfully dissects
HEADERS+CONTINUATION sent from nghttp.

​Best regards,
Tatsuhiro Tsujikawa​

---

From: Johnny Graettinger <[email-masked]>
Date: Fri, 27 Jun 2014 10:56:49 -0400

Chromium has accepted CONTINUATION frames since h2-12, and should be
sending CONTINUATION as of yesterday (when h2-13 changes landed). Headers
large enough to require them have been hit in interop testing, and I know
this because I get the bug reports and had initially omitted hooking them
up properly :)

I'm personally not that interested in talking about it, because I have
trouble keeping up with the list traffic as it is, and because I don't see
them as particularly burdensome to implement.

On Fri, Jun 27, 2014 at 8:26 AM, Tatsuhiro Tsujikawa <[email-masked]>
wrote:

>> As part of the next implementation draft and WGLC, we will assess how
>> well CONTINUATION is implemented, and any problems that it brings. If it's
>> found lacking, we’ll discuss alternatives. At this moment, though, we’re
>> not in a place where we’re going to abandon a feature or re-engineer the
>> protocol without cause; so far CONTINUATION has *not* come up as a problem
>> in the substantial body of running code that we have.
>>
> nghttp command line client included in nghttp2 has convenient option
> namely --continuation to send large headers with CONTINUATION to server for
> testing purpose.
>

---

From: Shigeki Ohtsu <[email-masked]>
Date: Sat, 28 Jun 2014 00:09:37 +0900

> if they did not show up recently they probably won't.

I (iij-http2) have already implemented CONTINUATION since it firstly 
came since draft-05. At every interop, I made several tests of 
HPACK+CONTINUATION with Chrome and Firefox by using iterative Ajax 
requests to add new headers with increase of thier header values.

As browser folks did great jobs at every interop, there were only tiny 
issues at CONTINUATION in the past and all tests worked fine after 
resolving several bugs.

I agree that CONTINUATION is not so much easy, but through my past 
interop tests, I think the current spec of CONTINUATION is enough to be 
stable and it does not cause serious issues in the future.

Regards,

---

From: Patrick McManus <[email-masked]>
Date: Fri, 27 Jun 2014 11:12:04 -0400

today's firefox nightly has h2-13 support btw. continuation support has
been around as long as its been in the spec, but we don't send them unless
there is just no room left in the headers.

I think pretty much nobody likes continuations, but we accept them as a
necessary long tail compatibility mechanism. It seems totally appropriate
for uninterested servers to 413 requests that use them - we certainly won't
generate a continuation unless we don't have another option. As with all
arbitrary limits (url length, etc..) allowing higher thresholds will buy
you interop at the tail - but you may not care about the tail.

-P

On Fri, Jun 27, 2014 at 10:56 AM, Johnny Graettinger <
[email-masked]> wrote:

> On Fri, Jun 27, 2014 at 8:26 AM, Tatsuhiro Tsujikawa <
> [email-masked]> wrote:
>
>>
>>
>>
>>> It’s great that Jetty is implementing now — welcome! — but
>>> characterising your objections plus that of other folks who haven’t
>>> implemented as an expert group vs. the editors’ whims is hugely
>>> disrespectful of the nearly 20 other implementations that have spent nearly
>>> two years working on this, not to mention the effort of the editors.
>>>

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 11:26:17 -0500

On Jun 27, 2014, at 10:12 AM, Patrick McManus <[email-masked]> wrote:

> 
> I think pretty much nobody likes continuations, but we accept them as a necessary long tail compatibility mechanism.

I’m glad you said that. This is a good basis to form consensus.

I am hoping that everyone can agree that:

1. Maintaining compatibility is good
2. Large headers should be discouraged
3. HOL blocking is bad in a multiplexed protocol - Although the severity varies according to topology. Topologies involving intermediaries are heavily impacted.
4. Framing limits are unlikely to change in anything other than an extension

It is possible to have a specification that does not concede any of these and still has minimal scope. #541 is one possibility. Matthew had at least one other option.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 27 Jun 2014 12:40:20 -0400

David,

> RFC 4559 appears to cover the culprit and appears to suggest that it is MSIE. Perhaps a Microsoft rep on this list can find out whether HTTP/2 support for SPNEGO Kerberos will be needed?

As someone that has implemented RFC 4559, the only thing that is particularly proxy-unfriendly is the size of Kerberos tickets from ActiveDirectory, which is a result of having all of the group/acl stuff for a particular user account being embedded in the ticket.  We settled for supporting a maximum Authorization header size of 64k (which means we allow up to about 48k worth of ticket information Base64-encoded) - this is sufficient for most sites but we occasionally see organizations/users with larger tickets and they just break/don't work...

Unfortunately, Kerberos tickets can also only be used once, so delta compression isn't going to be any help.  Every request uses a new Authorization header value, so this (along with security concerns) is why my HTTP/2 implementation will only use the Literal Header Field Never Indexed encoding for the Authorization header.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Jun 2014 09:59:27 -0700

> responsible for accomodating" ?

Yes, and I'm sensitive to your arguments.

> My proposal for jumboframes contain no restrictions that differ from

And your proposal is a perfectly reasonable one.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 27 Jun 2014 13:30:22 -0400

CUPS is currently not planning on supporting CONTINUATION frames.

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 14:34:05 -0500

> RFC might be able to get around this point.

It can’t affect the compressibility of subsequent requests because the large headers would be in the “uncompressed” frames[1]. Only the first HEADERS frame impacts the delta compression state.

[1] Uncompressed frames can actually still be compressed with HPACK with an effective table size of 0 for those frame if so desired.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Jun 2014 22:16:00 +0200

Hi Pat,

> you interop at the tail - but you may not care about the tail.

Then probably your and Johnny's choices indicate that there are at least
two reasonable implementations on the client side. Maybe we could make
the spec a bit stricter an only allow CONTINUATION frame if a header is
over 16kB and indicate that it is legal for the recipient to reject them
in any other case ? That would solve both sides of the problem :

  - recipients not interested in supporting more than 16kB do not need
    to implement them - at all -

  - there is no incentive for senders to produce them unless absolutely
    necessary, which ensures that recipients who do not implement them
    will never get into trouble below 16kB

Then we're exactly in the same situation we used to face with H/1 which
is that some implementations which do not support large enough headers
will simply reject the message, and nothing changes for anyone.

Would that be OK for every one ?

Willy

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 15:35:29 -0500

> Would that be OK for every one ?

IMO it doesn’t help that much. If recipients are not going to implement them then it should be an optional extensional vs an interop mess. Although, I honestly don’t understand why multiplexing has to be fundamentally broken to support large headers. Minimal changes can be done to resolve this problem. Sure it’s late in the process but better late than the pain of a problematic spec.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Jun 2014 22:46:53 +0200

On Fri, Jun 27, 2014 at 03:35:29PM -0500, Jason Greene wrote:
> IMO it doesn?t help that much. If recipients are not going to implement them
> then it should be an optional extensional vs an interop mess.

It already works like this in H/1 and that's not an issue at all. Basically
you find small headers over the net and large ones inside certain corporate
environments. Depending on where you deploy, you'll know that some components
are suited or not. It already works like this today and products adapt to
their target.

Willy

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 15:54:35 -0500

> are suited or not. It already works like this today and products adapt to

Sure but H/1 doesn’t implement multiplexing and state sharing. As you know, In H1 with a proxy you typically have a 1:1 client connection to the origin endpoint, so if one of the requests sense too big of a request it doesn’t really affect much. In H/2 if you coalesce it creates HOL problems and potentially kills the connection. Handling it is a PITA because there is no negotiation.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Jun 2014 22:57:37 +0200

On Fri, Jun 27, 2014 at 03:54:35PM -0500, Jason Greene wrote:
> Sure but H/1 doesn?t implement multiplexing and state sharing. As you know,
> In H1 with a proxy you typically have a 1:1 client connection to the origin
> endpoint, so if one of the requests sense too big of a request it doesn?t
> really affect much. In H/2 if you coalesce it creates HOL problems and
> potentially kills the connection. Handling it is a PITA because there is no
> negotiation. 

Yeah that's true, but my point is not to advocate for CONTINUATION frames,
rather to ensure that they're so useless that nobody uses them unless
everything is under total control on the whole chain. Then it will not
be that much of a problem for people taking the risk to pass extra-large
headers. They're already facing trouble today anyway.

Willy

---

From: Jason Greene <[email-masked]>
Date: Fri, 27 Jun 2014 16:17:31 -0500

> headers. They're already facing trouble today anyway.

Fair enough. If they aren’t fixed I think we will end up just disabling support for them by default, and if enabled disallow coalescing.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 28 Jun 2014 10:23:25 +0200

> Would that be OK for every one ?

It would help with my concern of Continuations being used as a DOS vector
with 1 byte per frame, so long as you are proposing text that say a send
MUST NOT have the END_HEADERS bit clear unless the frame is at max size?
Any receiving can treat non full frames without the END_HEADERS bit set as
a protocol error?

Note that it does not address my concern of code that is not used by 99.99%
of users but that complicates the handling of every frame and will only get
used/tested in a tiny minority of deployments.   Such code is asking to
contain lurking bugs and exploits.... however I think my fundamental
concern with continuations probably goes back to their jumbo frame nature
and hpack's single state table... so we would need a big rewrite to address
that.

cheers

---

From: Roberto Peon <[email-masked]>
Date: Sat, 28 Jun 2014 12:48:03 -0700

If you're concerned that headers are being sent a byte-at-a-time (slowloris
style), then you could do that with a regular headers frame anyway.
If you're concerned that the overhead of frames is blowing up the
bandwidth, then that could happen with PING, SETTINGS, DATA, etc. and is
not unique to HEADERS or HEADERS processing.
It is also point-to-point, and so any non-malicious client should be
unaffected by malicious clients.

The requirement to send END_HEADERS unless it is at max size adds a DoS
vector because it makes it impossible for a proxy to forward anything or
send anything until it has buffered the entire HEADERS, even when it has
all of the information necessary to figure out to which server it should
forward.

It is better to allow a proxy to forward data if it can.

-=R

On Sat, Jun 28, 2014 at 1:23 AM, Greg Wilkins <[email-masked]> wrote:

> Note that it does not address my concern of code that is not used by
> 99.99% of users but that complicates the handling of every frame and will
> only get used/tested in a tiny minority of deployments.   Such code is
> asking to contain lurking bugs and exploits.... however I think my
> fundamental concern with continuations probably goes back to their jumbo
> frame nature and hpack's single state table... so we would need a big
> rewrite to address that.
>
> cheers
>
>
>
>
> --

---

From: Jason Greene <[email-masked]>
Date: Sat, 28 Jun 2014 15:38:49 -0500

On Jun 28, 2014, at 2:48 PM, Roberto Peon <[email-masked]> wrote:

> If you're concerned that headers are being sent a byte-at-a-time (slowloris style), then you could do that with a regular headers frame anyway.
> If you're concerned that the overhead of frames is blowing up the bandwidth, then that could happen with PING, SETTINGS, DATA, etc. and is not unique to HEADERS or HEADERS processing.
> It is also point-to-point, and so any non-malicious client should be unaffected by malicious clients.
> 
> The requirement to send END_HEADERS unless it is at max size adds a DoS vector because it makes it impossible for a proxy to forward anything or send anything until it has buffered the entire HEADERS, even when it has all of the information necessary to figure out to which server it should forward.
> 

True, although if it does that the HOL blocking will force it to buffer all the other streams, so its not reliably helpful to break things up like that.

> It would help with my concern of Continuations being used as a DOS vector with 1 byte per frame, so long as you are proposing text that say a send MUST NOT have the END_HEADERS bit clear unless the frame is at max size?  Any receiving can treat non full frames without the END_HEADERS bit set as a protocol error?
> 
> Note that it does not address my concern of code that is not used by 99.99% of users but that complicates the handling of every frame and will only get used/tested in a tiny minority of deployments.   Such code is asking to contain lurking bugs and exploits.... however I think my fundamental concern with continuations probably goes back to their jumbo frame nature and hpack's single state table... so we would need a big rewrite to address that.
> 
> cheers
> 
> 
> 
> 
> --

---

From: Jason Greene <[email-masked]>
Date: Sat, 28 Jun 2014 15:48:08 -0500

On Jun 28, 2014, at 3:38 PM, Jason Greene <[email-masked]> wrote:

> True, although if it does that the HOL blocking will force it to buffer all the other streams, so its not reliably helpful to break things up like that

(forgot to say assuming coalescing)

-Jason

---

From: Roberto Peon <[email-masked]>
Date: Sat, 28 Jun 2014 13:47:59 -0700

When one is doing 1:1 proxying there is no real downside to allowing
transmission before the entire suite of headers has been received.
This is especially true if used for non-browser usecases.

When remuxing among multiple clients/servers, life is harder, and there are
a number of different tradeoffs.

-=R

On Sat, Jun 28, 2014 at 1:38 PM, Jason Greene <[email-masked]>
wrote:

> > If you're concerned that headers are being sent a byte-at-a-time
> (slowloris style), then you could do that with a regular headers frame
> anyway.
> True, although if it does that the HOL blocking will force it to buffer
> all the other streams, so its not reliably helpful to break things up like
> that.
>
>
> >
> > -=R
> >
> >
> >
> > It would help with my concern of Continuations being used as a DOS
> vector with 1 byte per frame, so long as you are proposing text that say a
> send MUST NOT have the END_HEADERS bit clear unless the frame is at max
> size?  Any receiving can treat non full frames without the END_HEADERS bit
> set as a protocol error?
> >

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 30 Jun 2014 10:34:02 +0200

> This is especially true if used for non-browser usecases.

Even if you do 1:1, if you perform security checks, you may need to
receive everything before you can decide to forward

(the other solution is to forward almost everything and cut the connexion
if the checks are negative once everything is received, but clients do not
like it much and it creates weird UI artefacts when download bars slow
down to a crawl at 99% Users hate those)

-- 
Nicolas Mailhot