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.
-----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 05:15:54 UTC