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:
>>> > Received on Thursday, 3 July 2014 12:57:54 UTC