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.
-=R


On Thu, Jul 10, 2014 at 8:11 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 11 July 2014 12:16, Greg Wilkins <gregw@intalio.com> 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 <gregw@intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com  advice and support for jetty and cometd.
>