RE: YAC Proposal

On 2014-07-03 17:15, Mike Bishop wrote:
> Used to be valid because the same APIs we have been using for HTTP/1
> will now transparently support HTTP/2 without change from the
> application above us.  We have some extreme corner cases for which
> we've discussed having to abort the response and turn it into a 505
> sending the request back to HTTP/1.1; I'd really rather not add
> another one, especially based on something we currently don't even
> check.
> 
> And again, the problem is simply that we're a general purpose server
> -- we *don't know* all scenarios where the application above us might
> be returning large headers.  We protect ourselves from large request
> headers as a DOS issue; large response headers, we don't block.
> 
> In your other mail, you suggested replacing clearing headers via
> Set-Cookie with an "application-layer construct" in the DATA frame, or
> with an extension that would presumably recreate all the required
> Set-Cookie commands at the 2-1 transition point.  Without changing
> HTTP semantics, I'm not really clear on how that would work.
> 

Thank you for the view into server design :-).

The design you have described is (almost) incompatible with HTTP/2 
requirement to treat HEADERS+CONTINUATION as a single "atomic" block. 
And leaves both you and the application at the mercy of upstream network 
hops.

Right now you are consuming network bandwidth, a TCP connection and RTT 
delays in order to punt generation of 400/414/431/500/502 error off to 
the remote end of that connection.

A small design change to buffer the generated headers from the 
application and send a single jumbo frame with known length will benefit 
your users greatly as you can then emit a 4xx/5xx error directly back to 
them immediately informing about the known jumbo-frame limit negotiated 
with the remote end of the connection. You will also be able to pass the 
entire header set to HPACK as a block and emit the resulting buffer as a 
single write, saving yourself a HOL-blocked outgoing connection while 
the application builds its header set.

Amos

> -----Original Message-----
> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
> Sent: Wednesday, July 2, 2014 6:49 PM
> To: ietf-http-wg@w3.org
> Subject: RE: YAC Proposal
> 
> On 2014-07-03 13:16, Mike Bishop wrote:
>> When I asked Osama about this, his immediate concern was about
>> response headers as well.  We cap incoming headers at 16KB (both
>> individual size and total header set) by default, with config options
>> to increase those as far as 64KB and 16MB if the administrator wants.
>> But we have no code that checks the size of response headers – we let
>> the client discard the response if they don’t like it.
>> 
>> That led to how we would deal with an app that tried to send something
>> that used to be valid and now isn’t.
> 
> Used to be valid in HTTP/2 or SPDY ?
>   ALPN and Upgrade tokens are (or should be) ensuring that both
> endpoints have the same spec version implemented. All this requires is
> a bump in the draft number.
> 
> Used to be valid in HTTP/1 ?
>   My last post to this thread reiterated the two know use-cases. We
> need to know of any other legitimate uses ASAP in order to determine
> how (or why not) they fit within the h2 protocol overall.
> 
> Amos
> 
>> 
>> From: Roberto Peon [mailto:grmocg@gmail.com]
>> Sent: Wednesday, July 2, 2014 5:43 PM
>> To: Jason Greene
>> Cc: Nicholas Hurley; K.Morgan@iaea.org; IETF HTTP WG
>> Subject: Re: YAC Proposal
>> 
>> I wonder how many servers don't. I don't know of any major servers
>> with such a cap, but I'm surely in the dark.
>> Do we know how many place a cap on the size of response headers?
>> 
>> If just about everything supports it, why would it be an extension?
>> -=R
>> 
>> On Wed, Jul 2, 2014 at 5:38 PM, Jason Greene
>> <jason.greene@redhat.com<mailto:jason.greene@redhat.com>> wrote:
>> Sure every server that supports > 16KB of compressed header data will
>> implement the extension, or perhaps another extension :) Either way
>> the end result is the same.
>> 
>> On Jul 2, 2014, at 7:33 PM, Roberto Peon
>> <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
>> 
>>> Is the extension guaranteed to be supported everywhere?
>>> If not, then HTTP2 doesn't offer HTTP1's semantics.
>>> -=R
>>> 
>>> 
>>> On Wed, Jul 2, 2014 at 5:32 PM, Jason Greene
>>> <jason.greene@redhat.com<mailto:jason.greene@redhat.com>> wrote:
>>> Compatibility isn’t really affected here. You simply use the
>>> extension if you wish to accept > 16KB of compressed header data.
>>> HTTP/1.1 servers were not required to support it any more than they 
>>> are today.
>>> 
>>> On Jul 2, 2014, at 7:21 PM, Roberto Peon
>>> <grmocg@gmail.com<mailto:grmocg@gmail.com>> wrote:
>>> 
>>> > One cannot remove continuation without addressing backwards compatibility with HTTP/1.1 deployments sending large headers.
>>> >
>>> > The status quo, or a variation which improves the state machine
>>> > around continuation (e.g. by moving the flags to the last frame of
>>> > the headers block) makes the most sense to me -=R
>>> >
>>> >
>>> > On Wed, Jul 2, 2014 at 4:22 PM, Nicholas Hurley <hurley@todesschaf.org<mailto:hurley@todesschaf.org>> wrote:
>>> > This sounds like a non-starter, to me. As mentioned in the other
>>> > thread, I prefer either the status quo, or failing that a stateless
>>> > CONTINUATION. This seems worse to me than either of those options.
>>> > With a stateless CONTINUATION, in the rare occasions when I'll
>>> > encounter a compressed header block > 16k, I can roll back just one
>>> > step in my HPACK compression, and then continue on sending an
>>> > uncompressed form of the headers. With CONTINUATION as an
>>> > extension, when the other side doesn't advertise support, I would
>>> > either have to either roll back the entire HPACK state that I
>>> > changed when trying to compress the headers and generate a
>>> > RST_STREAM (likely synthesizing an 413 or some other error in the
>>> > process for my own side), or I'd have to send a GOAWAY, and dial
>>> > back. Neither of those options is in any way more appealing than
>>> > stateless CONTINUATION (which I'm still not entirely sold on to
>>> > begin with!)
>>> >
>>> > --
>>> > Peace,
>>> >   -Nick
>>> >
>>> >
>>> > On Wed, Jul 2, 2014 at 12:51 PM, <K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>> wrote:
>>> > I'd like to propose yet another option to Mark's list of options for dealing with the "CONTINUATION issue".
>>> >
>>> > Make it an extension.
>>> >
>>> > In NYC several people mentioned that if we add extensibility, we should have an extension(s) right from the start that are used.  CONTINUATION IMO is a good option for an extension.
>>> >
>>> > Here is the CONTINUATION extension draft:
>>> > http://www.ietf.org/id/draft-johndoe-http2-large-header-blocks-00.t
>>> > xt
>>> >
>>> > Here is the pull request to remove CONTINUATION from the core h2 draft:
>>> > https://github.com/http2/http2-spec/pull/547
>>> >
>>> > -keith
>>> >
>>> > 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.
>>> >
>>> >
>>> >
>>> 
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red
>>> Hat
>>> 
>>> 
>> 
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red
>> Hat

Received on Thursday, 3 July 2014 12:57:54 UTC