Subject: [quicwg/base-drafts] Rationalise Server-Push-specific rejection error codes (#2812)

From: Lucas Pardue <[email-masked]>
Date: Wed, 19 Jun 2019 04:00:41 -0700

RFC 7540 section 8.2.2 states:

>   If the client determines, for any reason, that it does not wish to
   receive the pushed response from the server or if the server takes
   too long to begin sending the promised response, the client can send
   a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code
   and referencing the pushed stream's identifier.

HTTP/3 changed push a bit and introduced two error codes: HTTP_PUSH_REFUSED and HTTP_PUSH_ALREADY_IN_CACHE. These is extra fidelity on top of HTTP/2, clearly articulating if the pushed item is in cache or not. This may be seen as useful, however there are some practical downsides:

* The CANCEL_PUSH frame exists and is the first RECOMMENDED action for declining a push. This does not expose the reason
* In actuality, server push caching is murky, which may affect the amount of confidence an operator could put into analyising these error codes.

I think it is simpler, more self-consistent, and mroe HTTP/2-consistent to have one error code for server push. I'll prepare a PR for this.

-- 
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/2812

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 05:37:32 -0700

I agree that we can remove HTTP_PUSH_ALREADY_IN_CACHE.

In addition, I think we might also want to remove CANCEL_PUSH in favor of using REQUEST_CANCELLED. IIUC, the semantics of CANCEL_PUSH can be (or can be) exactly the same as REQUEST_CANCELLED after the client has sent the entire request.

-- 
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/2812#issuecomment-503542317

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 19 Jun 2019 06:07:08 -0700

> In addition, I think we might also want to remove CANCEL_PUSH in favor of using REQUEST_CANCELLED. IIUC, the semantics of CANCEL_PUSH can be (or can be) exactly the same as REQUEST_CANCELLED after…

Clarification, do you mean:

1. replace the HTTP_PUSH_REFUSED error with HTTP_REQUEST_CANCELLED error?
2. remove CANCEL_PUSH frame altogether and replace the function by sending a STOP_SENDING with HTTP_REQUEST_CANCELLED error?

I don't think option 2 is possible, the purpose of CANCEL_PUSH frame is to stop pushes before any stream is created - at that point there is no stream ID to reference.

-- 
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/2812#issuecomment-503552535

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 19 Jun 2019 06:09:08 -0700

Also, option 1 then deviates from HTTP/2 that had "REFUSED_STREAM" and "CANCEL" error codes/

-- 
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/2812#issuecomment-503553305

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 06:19:06 -0700

Apologies. I meant option 1.

> Also, option 1 then deviates from HTTP/2 that had "REFUSED_STREAM" and "CANCEL" error codes.

REFUSED_STREAM (of HTTP/2) maps to HTTP_REQUEST_REJECTED (of HTTP/3). CANCEL (of HTTP/2) maps to HTTP_REQUEST_CANCELLED (of HTTP/3).

Therefore, it is safe to combine HTTP_PUSH_REFUSED to HTTP_REQUEST_CANCELLED.

HTTP_PUSH_REFUSED error is used after the server processes the request, therefore the semantics is same as CANCELL, not REFUSED_STREAM.

-- 
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/2812#issuecomment-503556969

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 19 Jun 2019 06:34:40 -0700

Thanks for clarifying, I agree with this and will incorporate it into this PR.

-- 
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/2812#issuecomment-503562983

---

From: Mike Bishop <[email-masked]>
Date: Thu, 27 Jun 2019 14:36:44 -0700

Closed #2812 via #2813.

-- 
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/2812#event-2445648312