- From: Jason Greene <jason.greene@redhat.com>
- Date: Thu, 26 Jun 2014 14:53:06 -0500
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Jun 26, 2014, at 2:37 PM, Greg Wilkins <gregw@intalio.com> wrote: > > On 26 June 2014 19:49, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > One example is Kerberos tickets, which can be up to 64KB (after Base64 encoding). While they’re a tiny fraction of requests on the Internet, they exist in HTTP/1.1. > > As many parts of http infrastructure have a defacto 8kB header limit, then any traffic with 64KB headers is only going to work with prior agreement between client, intermediaries and servers. Sounds like a negotiated extension to me > > With the current h2 draft, many implementation will probably not support continuations at all, so such kerberos tickets are likely to receive a 413 response unless there is prior negotiation along the path. There is not even a mechanism to determine the max size supported by a path, only rejection if something is too big. Surely a negotiated big header extension would be better than this uncertainty? That’s a gerat point. From a proxy perspective CONTIUATION, as it is currently defined, is flat out evil. If you attempt to coalesce multiple connections (be it http/1.1, spdy, or http/2), you ideally want to multiplex it all, and perhaps even forward it, which will work great up until the point that one client out of all of the aggregated clients decides to misuse CONTINUATION. After that point chaos reigns, and connections start dropping everywhere. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 26 June 2014 19:53:49 UTC