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


From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 4 Jul 2014 00:08:51 +1000
Message-ID: <CACweHNAEZ3yR2P6HYa6t1NfUbyNNqEOV=uFqG6+pv=2HcX+TpQ@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Jason Greene <jason.greene@redhat.com>, Greg Wilkins <gregw@intalio.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
​On Jul 2, 2014, at 9:20 PM, Mike Bishop <Michael.Bishop@microsoft.com>
> The real question with such an extension is the reverse direction -- does
the client also advertise their maximum response header size?  What should
a server do if the request a client sent produces a response the client
isn't going to accept due to header size?​

I think the options are either: downgrade to 1.1, send a 4xx response, or
send a 5xx response. I want to say 406, but not quite. In any case, with a
400 or 500 you can explain in plain text (or HTML) what the problem is, and
maybe even how to fix it (or at least to give up); not so easy with a

On 3 July 2014 23:45, Michael Sweet <msweet@apple.com> wrote:

> Based on some of the other discussions about max header sizes for proxies,
> and given the confusion that would ensue concerning "sent" and "received"
> header size settings, I would say there should just be one limit for both
> directions.
Settings simply say "this is what I will accept." You don't have to
advertise what you'll send -- just send it. If you say you're willing to
receive 64K and the other guy is willing to receive 16K​, who knows, *e
might send you 64K. Odds are against it, though. Whether you're upstream or
downstream or it's a request or a response isn't relevant, at this level.

  Matthew Kerwin
Received on Thursday, 3 July 2014 14:09:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:08 UTC