Subject: [quicwg/base-drafts] Iinvalid Push ID error codes (#2818)

From: Lucas Pardue <[email-masked]>
Date: Thu, 20 Jun 2019 07:43:15 -0700

There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTP_DUPLICATE_PUSH with an HTTP_PUSH_ID_ERROR code. and replacing use of HTTP_MALFORMED frame.

| Condition  | Current | Proposed |
| ------------- | ------------- | ------------- |
| Promise with ID larger than current limit  | HTTP_MALFORMED_FRAME  | HTTP_LIMIT_EXCEEDED |
| Promise with ID already used | HTTP_MALFORMED_FRAME  | HTTP_PUSH_ID_ERROR |
| ID limit reduced | HTTP_MALFORMED_FRAME  | HTTP_PUSH_ID_ERROR |
| Duplicate promise with ID larger than current limit  | HTTP_MALFORMED_FRAME  | HTTP_LIMIT_EXCEEDED |
| Push stream with ID already used | HTTP_DUPLICATE_PUSH | HTTP_PUSH_ID_ERROR |

Note, on #2662 I suggested a slightly different solution to replace HTTP_MALFORMED FRAME, but I think this is a better path.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2818

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Jun 2019 22:29:45 -0700

To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like PLACEHOLDER_ID_ERROR, STREAM_ID_ERROR.

Also, using PUSH_ID_ERROR in some cases while using MALFORMED_FRAME in others seems confusing.

I think we might want to consider doing either of the two:
* Use PUSH_ID_ERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3
* Introduce ID_ERROR that captures all the limit and ID errors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2818#issuecomment-504295038

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Jun 2019 02:37:07 -0700

Thanks @kazuho. The proposal is a bit of a compromise, so I agree with some of the points that you make.

I like your idea of replacing HTTP_LIMIT_EXCEEDED with HTTP_ID_ERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics.

What follows is the response I made first, before coming to that agreement :)

> To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things lik…

Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTP_LIMIT_EXCEEDED.

Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions.

However, server push is a little different because it's ID space is managed by the MAX_PUSH_ID frame. The three errors that use HTTP_PUSH_ID_ERROR are unique to push. However, if we modified HTTP_LIMIT_EXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTP_ID_ERROR) I think that would work.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2818#issuecomment-504362218

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Jun 2019 02:52:52 -0700

I updated the PR #2820  with the above, so that we can see what it looks like. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2818#issuecomment-504366978

---

From: Mike Bishop <[email-masked]>
Date: Fri, 21 Jun 2019 09:26:33 -0700

I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me.  I suspect that means I don't actually disagree, I just need some time to wrap my head around it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2818#issuecomment-504487037