Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

[Martin Thomson <[e-mail]>]

On 3 May 2013 14:43, Roberto Peon <[e-mail]> wrote:
> No argument there. Except for the issue with the lifetime of headers, it is
> a very pretty design (the only thing you end up having to change is the
> strict requirement on stream ID mentions being in monotonic order, which
> we're loosening anyway for push). As a matter of fact this was one of the
> ways we had discussed for SPDY/1 :)

I don't see headers being a property of the streaming or framing
layers, so I never really considered this to be a problem.  The fact
that they live beyond the lifetime of a single stream direction
doesn't mean that you need to change how you write your code.

To give another case, headers already need to live beyond the lifetime
of both directions of a stream when that stream triggers a push.

> In general any server/proxy/loadbalancer will wish to keep headers about for
> the shortest time period possible as they typically represent either the
> largest or a very large chunk of the state the server keeps resident. It is
> possible to do fancy/complicated things to reduce this burden.. but they're
> fancy/complicated :)

Wasn't that always true though?  I can't imagine that a high
performance server would be holding strings for most headers.  The
only cases that might be needed for are cookies (as always).