Subject: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

From: James M Snell <[email-masked]>
Date: Tue, 18 Jun 2013 23:00:28 -0700

https://github.com/http2/http2-spec/issues/140

Currently, we have the FRAME_TOO_LARGE error code...

However, it's possible that a frame can be under-sized. For instance,
a PING frame with less than 8-bytes of payload. We don't have a good
symmetrical approach to handling both over, and undersized frames. One
suggestion is to remove FRAME_TOO_LARGE entirely and just use
PROTOCOL_ERROR but that loses value, I think. Having specific error
codes is a good thing at times. Changing to FRAME_SIZE_ERROR allows us
to deal easily with over and undersized frames symmetrically.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 19 Jun 2013 18:55:16 +1000

Oops, I sent this to James only.

Is it worth differentiating between too many and too few bytes?  Or is
the expectation that bad frames always means the peer is misbehaving,
so we're simply resetting the stream or telling them to go away?

-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Jun 2013 08:12:24 -0400

On Wed, Jun 19, 2013 at 2:00 AM, James M Snell <[email-masked]> wrote:

> PROTOCOL_ERROR

yes, let's do that! FRAME_TOO_LARGE's purpose was when the frame exceeded
client capacity - not for malformed packets. With the new smaller frame
sizes that bit of complexity can and should just go away.

---

From: David Morris <[email-masked]>
Date: Wed, 19 Jun 2013 07:41:37 -0700 (PDT)

> sizes that bit of complexity can and should just go away.

I think more information on error conditions is almost always better. The
recipient should always beable to fold multiple codes into one if they
insist.

In any case, I haven't seen a discussion on the list, but at the interim
meeting, the maximum was pushed up to HTTP while allowing the framing
layer to retain the 64k limit implied by the field size. That seems to
me to mean that the http layer could still need to send the TOO_LARGE
error.

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Jun 2013 07:56:23 -0700

FRAME_SIZE_ERROR allows us to easily deal with both over and under sized
frames with no additional complexity or weirdness.
Overuse of PROTOCOL_ERROR will not be a good thing long term.

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 19 Jun 2013 08:02:15 -0700

The HTTP limit has to do with the size of the data frames -- we want to
limit how much data the peer can place in a given frame to improve
responsiveness to events like re-prioritization.

As an implementation you probably would not send a connection or stream
error on receipt of a data frame larger than 16 KB, you would just
internally divide the received frame into 16 KB chunks and process them in
sequence.

If the http layer does need to send a "TOO_LARGE" error, it has a mechanism
to do so at that layer of the protocol -- 413 Request Entity Too Large

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Jun 2013 09:27:02 -0700

One can't know that a frame is too small, though, unless there is a time
limit or other constraint on the sending of the frame.
Even then, packet loss can make the end of a frame disappear.

Is there a real case where frame size too small could be emitted with
confidence?

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Jun 2013 09:29:19 -0700

But that error code refers to the entire entity size, which is not the
frame size. One could send 1 byte per frame and still get that http error
code.
On Jun 19, 2013 8:04 AM, "Jeff Pinner" <[email-masked]> wrote:

> If the http layer does need to send a "TOO_LARGE" error, it has a
> mechanism to do so at that layer of the protocol -- 413 Request Entity Too
> Large
>
>

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 19 Jun 2013 09:32:56 -0700

1 byte per data frame is completely legal at both the framing layer and the
application layer. I believe the only illustrating examples here are
something like sending a 7 byte PING frame or a 3 byte WINDOW_UPDATE frame.
You have received the entire frame, it is just malformed.

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Jun 2013 09:34:05 -0700

> Is there a real case where frame size too small could be emitted with

If I send a PING frame with a length field < 8... Or a PRIORITY frame
with length field < 4 ..

Either way, you're right that too small is hard to judge (and
therefore hard to justify having a "frame too small" error... which is
why I opted for the more generic "FRAME_SIZE_ERROR" to cover both
over- and under-size conditions. Either way, there's a problem with
the frame size.

- James

---

From: Roberto Peon <[email-masked]>
Date: Wed, 19 Jun 2013 09:47:22 -0700

Are either of those length requirements expressed at the http layer (I
don't think they should be if they are).
I think these are protocol errors at the session or framing layer.

On the 417 thing-- I was trying (poorly :( ) to express that http status
codes are unlikely to be useful at indicating problems at the applications
protocol layer of http/2 since that becomes ambiguous.

-=R
On Jun 19, 2013 9:32 AM, "Jeff Pinner" <[email-masked]> wrote:

> 1 byte per data frame is completely legal at both the framing layer and
> the application layer. I believe the only illustrating examples here are

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jun 2013 10:22:30 -0700

> You have received the entire frame, it is just malformed.

So, I have a question:  is there an actionable difference between
FRAME_SIZE_ERROR and PROTOCOL_ERROR.  Noting that neither RST_STREAM,
nor GOAWAY, have a way to indicate which frame was in error, there
isn't much that is actionable in either case.  I believe that the
action in both cases is the same: go and debug your stack.

That leads me to conclude that this is error code proliferation for no
good reason.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Jun 2013 10:28:48 -0700

On Wed, Jun 19, 2013 at 10:22 AM, Martin Thomson
<[email-masked]>wrote:

> the

Actionable difference: it tells you what part of your stack to debug.
PROTOCOL_ERROR is terrible :( Everytime we generate a PROTOCOL_ERROR, we
have felt we wanted to add a debug string (that opaque byte sequence we
discussed earlier) so we could figure out what was wrong.

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Jun 2013 10:34:38 -0700

+1... overloading PROTOCOL_ERROR is very very bad.

On Wed, Jun 19, 2013 at 10:28 AM, William Chan (陈智昌)
<[email-masked]> wrote:
> On Wed, Jun 19, 2013 at 10:22 AM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jun 2013 10:58:50 -0700

> discussed earlier) so we could figure out what was wrong.

I thought that was the reason you wanted to put the opaque stuff in the body.

The reason I'm pushing back is that it is possible to spend error code
bits on any amount of subdivision of the PROTOCOL_ERROR space.  Do you
want one for the case where someone didn't echo the bytes of a PING?
Or when they decide to send something else rather than continuing a
HEADERS block?  Or any of the many current and future
your-implementation-is-broken cases?  Ultimately, this just leads to a
blowout in error codes, to no good end.

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Jun 2013 11:05:13 -0700

For now, in the implementation draft, can we keep this focused on whether
or not to rename this one existing error code rather than expand into too
much philosophical debate about error codes in general? We can refine the
error code mechanism if necessary later on.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jun 2013 11:13:06 -0700

On 19 June 2013 11:05, James M Snell <[email-masked]> wrote:
> can we keep this focused on whether or not to rename this one existing error
> code

I think that renaming becomes moot if the code disappears.

I can perform a search and replace as well as any man, if consensus is
against me (as it appears to be).  But please don't shortcut the
discussion.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Jun 2013 14:15:21 -0400

let's consider it this way.. has any implementation found FRAME_TOO_LARGE
to be useful (outside of the case of implementations not wanting to handle
frames > 64KB which is now not a factor)? If not, then it should go. If so,
then I guess it should stay.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Jun 2013 11:29:04 -0700

> I thought that was the reason you wanted to put the opaque stuff in the

Kinda. Btw, my earlier answer (which I now realize is slightly wrong, since
it really applied to INTERNAL_ERROR) was just to say that it does have an
actionable difference, and that generic error codes without debug strings
suck. I don't really mind as long as we have the opaque bytes. Here would
be my high level points on this topic.

* Error codes are insufficient. There are an infinite number of possible
errors that could happen at a different layer that it would be nice to have
opaque bytes for (e.g. reverse proxy INTERNAL_ERROR, where errors come from
the proxy's backend).
* Error codes are nice if you're going to have automated handling of
certain error codes. I don't believe that applies here.
* Error codes are also nice if you need to standardize a way for one
endpoint to inform the other endpoint of its error. INTERNAL_ERROR with
debug strings works fine when the receiver of the error code and opaque
bytes can just send the opaque bytes out of band back to the original
sender. But a PROTOCOL_ERROR is a way for the error code sender to tell the
receiver that it was Doing It Wrong. So an opaque explanation here doesn't
do much. A finer grained error code might be helpful.

> blowout in error codes, to no good end.

Reasonable position and I don't really care. Just wanted to explain the
"actionable difference".