W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #540: "jumbo" frames

From: Jason Greene <jason.greene@redhat.com>
Date: Fri, 27 Jun 2014 13:57:00 -0500
Cc: Martin Thomson <martin.thomson@gmail.com>, Greg Wilkins <gregw@intalio.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DFBEC1C3-9C75-4D5F-BDD7-003ECD8636F3@redhat.com>
To: Michael Sweet <msweet@apple.com>

On Jun 27, 2014, at 1:53 PM, Michael Sweet <msweet@apple.com> wrote:

> Jason,
> 
> On Jun 27, 2014, at 2:31 PM, Jason Greene <jason.greene@redhat.com> wrote:
>> On Jun 27, 2014, at 1:08 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>> 
>>> On 27 June 2014 11:05, Michael Sweet <msweet@apple.com> wrote:
>>>>> b) you receive a CONTINUATION frame?
>>>> 
>>>> 413
>>> 
>>> And the header compression state changes it might contain?  Or are you
>>> setting the header table to size 0
>> 
>> Even if you set table size to 0 you still have to process them before you can return a 413, since the setting is delayed. and you might get them before it takes effect. Only way to not process them is GOAWAY + close.
> 
> How does a client know not to reconnect and try the same request again after getting a GOAWAY?

Sorry I was trying to say “just a 413”. you can of course send the 413 before you do the GOAWAY.

Slight tangent - 413 might not match the situation if the client is sending continuations who’s total is < 16 KB or whatever your limit is.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Friday, 27 June 2014 18:57:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC