[quicwg/base-drafts] Echoing HTTP_REQUEST_CANCELLED from STOP_SENDING has unintended semantics (#2106)

[afrind <[e-mail]>]

The current transport draft says:

>   A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An  endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame for that stream. An endpoint SHOULD copy the error code from the STOP_SENDING frame, but MAY use 
any other application error code. The endpoint that sends a STOP_SENDING frame can ignore the 
error code carried in any RESET_STREAM frame it receives.

For HTTP, the HTTP_REQUEST_CANCELLED application error code has different semantics in each direction.  From C -> S, it means "I don't want this".  From S -> C, it means "I didn't process this".  I don't think the client can't distinguish whether the RESET_STREAM was sent before or after the STOP_SENDING was received.

Maybe it's ok to do nothing here, since the client isn't likely to attempt to retry the request it just abandoned, and the text says the sender can ignore the RESET_STREAM error code.  Or maybe we should clarify it in some way.

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