Subject: [quicwg/base-drafts] Transport shouldn't be cancelling streams (#485)

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Apr 2017 00:07:09 -0700

@ekr asked which code a server might use to cancel streams that exceed a revised limit after 0-RTT in #479.

My initial response was CANCELLED, which I'm adding in #467.  However on reflection I think that might be a category error.  The application protocol should be the one to cancel things and we should use the HTTP-defined HTTP_REQUEST_CANCELLED instead.

The reason being twofold:

* On general principles, the transport shouldn't be cancelling streams without first consulting the application layer; what if the transport cancelled stream 3 (or maybe stream 1)?  To the transport that's not special

* Signaling the ability to retry is easier at the application layer.  At the transport layer the only way to distinguish between retryable and not is to ask whether any bytes were passed to the application layer.  At the application layer, even if bytes were delivered, the application might still be able to cancel without side effects.

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

---

From: ekr <[email-masked]>
Date: Fri, 28 Apr 2017 00:45:48 -0700

Hmm... So if I host netconf over QUIC, I need to invent a new error code for this? That's definitely going to need some guidance to app protocol designers.

-- 
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/485#issuecomment-297931528

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Apr 2017 20:59:09 -0700

The alternative is to say that they can all use the same error code, but the application layer might not bind state to a specific stream in a way that cancellation even makes sense.

Once again, we encounter a hazard imposed by only having one application.

-- 
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/485#issuecomment-298282437