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

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 16 Sep 2013 18:17:37 -0700

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.

---

From: Gábor Molnár <[email-masked]>
Date: Wed, 18 Sep 2013 10:37:08 +0200

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