Re: Error code for PING frame with wrong size - https://github.com/http2/http2-spec/issues/246

So, regarding the error code discussion:

In case of an INTERNAL_ERROR, the opaque data may be opaque to every
participant except the originator. But in case of a PROTOCOL_ERROR,
opaque data may be opaque to the HTTP/2 implementation itself, but not
to the people debugging it. For example, an good implementation could
attach a sensible error message like this (encoded in ASCII): "DATA
frame on stream 5 is oversized.". It's more informative than
FRAME_SIZE_ERROR in itself when it comes to debugging.

But anyway, how can we force implementations to return sensible error
codes? A bad implementation could return PROTOCOL_ERROR in case of a
frame size error if it wanted to, without ever getting into trouble...

2013/9/17 William Chan (陈智昌) <willchan@chromium.org>:
> Moving over from github.
>
> Gabor:
> ==========
> Currently, there's two contradicting MUSTs for this.
>
> Section 4.2::
>
> Certain frame types, such as PING (see Section 6.7), impose
> additional limits on the amount of payload data allowed.  Likewise,
> additional size limits can be set by specific application uses (see
> Section 9).
>
> If a frame size exceeds any defined limit, or is too small to contain
> mandatory frame data, the endpoint MUST send a FRAME_TOO_LARGE error.
> Frame size errors in frames that affect connection-level state MUST
> be treated as a connection error (Section 5.4.1).
> Section 6.7:
>
> Receipt of a PING frame with a length field value other than 8 MUST
> be treated as a connection error (Section 5.4.1) of type
> PROTOCOL_ERROR.
> I propose to simply omit the second one, or just reference the former
> section.
> ==========
>
> See https://github.com/http2/http2-spec/issues/246 for the rest of the
> discussion.

Received on Wednesday, 18 September 2013 08:37:58 UTC