- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 27 Jun 2014 13:57:00 -0500
- To: Michael Sweet <msweet@apple.com>
- 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>
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