implementation-defined limits on variable-length fields?

[Adrian Quark]

The draft 3 spec does not appear to contain any provisions for
implementation-defined limits on the size or number of headers, for
example. Since implementations may wish to limit the size of requests
they will accept, it would be helpful if the spec included reasonable
minimum sizes which all implementations must support, and specified
behavior in case either party exceeds the limits imposed by the
implementation. For example, perhaps SPDY should specify an
RST_STREAM status code which is equivalent to the HTTP status code 413
"Request Entity Too Large".

[Mike Belshe]

I can't think of many reasons *not* to.  If we didn't, I guess implementations would just use REFUSED_STREAM.

How about "REQUEST_TOO_LARGE"

Mike

[Mark Nottingham]

Is this something that you really want to do in SPDY? Why not just reuse the existing HTTP status codes? That would make things much simpler both for APIs and gateways.

Also, in HTTPbis we're taking the approach of suggesting (but not requiring) some minimum supported sizes for various protocol elements like headers, URIs, etc. See:

Cheers,

--
Mark Nottingham
http://www.mnot.net/

[Mike Belshe]

On Thu, Dec 22, 2011 at 6:26 AM, Mark Nottingham <mn...@mnot.net> wrote:

Is this something that you really want to do in SPDY? 

Why not just reuse the existing HTTP status codes? That would make things much simpler both for APIs and gateways.

HTTP already has this - there currently is no solution for this at the framing layer.  To have the framing layer generate a HTTP response seems like a mistake?  There is also a question about stream-level errors vs session level errors.  I'll come up with something.

 

Also, in HTTPbis we're taking the approach of suggesting (but not requiring) some minimum supported sizes for various protocol elements like headers, URIs, etc. See:

That sounds great.

Mike

[Adrian Quark]

Mike Belshe writes:
> I can't think of many reasons *not* to. If we didn't, I guess implementations would just use REFUSED_STREAM.
> How about "REQUEST_TOO_LARGE"

That sounds fine to me.

Mark Nottingham writes:
> Is this something that you really want to do in SPDY? Why not just reuse the existing HTTP status codes? That would make things much > simpler both for APIs and gateways.

As an implementor, I could probably live with that, but it feels
slightly inconsistent, for several reasons.

First, the SPDY spec carefully specifies the SPDY framing protocol
independently of the encoding of HTTP messages. The limits I'm
concerned with pertain to the SPDY framing protocol whether it's used
for HTTP or not. So it's perfectly reasonable for someone to
implement a "pure" SPDY library without the HTTP layering, and in this
case they would still need some way of dealing with oversized
messages.

Second, sending a SYN_REPLY does not fully close the stream, so the
sender would be free to continue sending frames and the receiver would
be obligated to accept and discard them, unless the SYN_REPLY was
followed immediately by an RST_STREAM. Since we want to immediately
close both sides of the stream, why not send just the RST_STREAM and
skip the SYN_REPLY?

Third, unidirectional streams do not allow for any kind of HTTP
SYN_REPLY, so clients would have to use a different mechanism to
reject push streams with too many headers.

Finally, I don't see how encoding this error in a SYN_REPLY would make
anything simpler. APIs and gateways already have to handle
REFUSED_STREAM, which has similar semantics. Adding another status
code just provides more useful information to explain why the stream
was refused.

[Mike Belshe]

I've added a FRAME_TOO_LARGE code for a RST_STREAM, and allowed it for use with SYN_STREAM and SYN_REPLY.

I also added Mark's suggestion to specify minimum control frame sizes.  httpbis went with 8000 bytes (Mark, correct me if I wasn't looking at the latest draft), so for SPDY this becomes 8000 + max control frame header size (20).  I used 8192.

I believe this is most important for control frames.  I considered adding limits for data frames, but decided this is not a good idea, since data frames should be streamable and even the smallest devices should be able to handle them without exorbitant buffering problems.  If the higher level data size is really too large, there the HTTP layer (or whatever SPDY is carrying) can deal with too-large errors.  But from the framing layer, implementations must support full sized data frames to be compliant.

Mike

[Mike Belshe]

BTW - it also occurred to me that when this happens, you're probably going to have to error out the entire session rather than just a stream.  If an implementation doesn't fully process the compressed data within a SYN_STREAM, SYN_REPLY, or HEADERS frame, then the compression state between the endpoints get out of sync.  Once that happens, you have to tear down the entire session.

Mike

[Patrick McManus]

On 2/11/2012 3:37 PM, Mike Belshe wrote:
> BTW - it also occurred to me that when this happens, you're probably
> going to have to error out the entire session rather than just a
> stream. If an implementation doesn't fully process the compressed
> data within a SYN_STREAM, SYN_REPLY, or HEADERS frame, then the
> compression state between the endpoints get out of sync. Once that
> happens, you have to tear down the entire session.

yes - some language around this is probably very helpful in the spec .

I made the mistake, when rst_stream'ing sever pushes that I did not want
to accept, of not processing the compressed headers.. which of course
led to the same class of bug.

[Antonio Vicente]

On Sat, Feb 11, 2012 at 3:37 PM, Mike Belshe <mbe...@chromium.org> wrote:

BTW - it also occurred to me that when this happens, you're probably going to have to error out the entire session rather than just a stream.  If an implementation doesn't fully process the compressed data within a SYN_STREAM, SYN_REPLY, or HEADERS frame, then the compression state between the endpoints get out of sync.  Once that happens, you have to tear down the entire session.

A minimum on the decompressed size would be good.

At the framer level, it is possible to process all SPDY frames using only a small constant size buffer.  In the case of SYN_STREAM and SYN_REPLY, you can decompress the header data incrementally and hand off the uncompressed bytes to the application.  You could do the decompression and throw out the result in order to keep the connection open.

-antonio