Re: Large Frame Proposal

I think you're arguing for things at the semantic layer, not he framing
layer-- right now one of the proposals *is* that we treat headers
differently by only allowing them to exist in one frame, which is not how
data is treated.

On Thu, Jul 10, 2014 at 8:11 PM, Greg Wilkins <> wrote:

> On 11 July 2014 12:16, Greg Wilkins <> wrote:
>> I can't live with 16 bit length.
> Just to expand why I cannot live with 16 bit lengths.
> I can already see valid use-cases today that exceed 16 bit lengths.   We
> have decided that 64KB kerberos tickets are acceptable and necessary to
> support, so a kerberos authenticated proxy talking to a kerberos
> authenticated server will need two such tickets and that will not fit into
> a 16bit header block.
> So that use-case will just drive fragmentation of headers (continuations
> by another name), which breaks the entire purpose of this proposal.
> Either we have frames large enough to carry all acceptable headers - or we
> need to go back to basics and come up with a framing layer that does not
> treat headers specially.
> regards
> --
> Greg Wilkins <>
> HTTP, SPDY, Websocket server and client that
> scales
>  advice and support for jetty and cometd.

Received on Friday, 11 July 2014 03:17:57 UTC