HTTP-31: Server SHOULD send CANCEL_PUSH

[gloinul]

In Section 7.2.3: https://www.ietf.org/archive/id/draft-ietf-quic-http-31.html#name-cancel_push

A server SHOULD send a CANCEL_PUSH frame even if it has opened the corresponding stream.

Is the intention that this sentence should have this meaning?

"A server that has opened a stream for a PUSH and is unable to fulfill this promise SHOULD send a CANCEL_PUSH frame with the corresponding Push ID."

I think as currently formulated it is missing the criteria as well when this may occur.

Secondly the alternative is also not clear. I assume this is a SHOULD as the stream can be reset with an error code? Does that need to be added and which error will be used? Especially as the next paragraph only discusses that the client SHOULD abort reading. Can't the server terminate the stream from its side? If only the later is allowed, I think that should be made explicit but appears unnecessary.

[LPardue]

To the second question, stating clearly that the server can abort the Push stream with H3_REQUEST_CANCELLED seems like a good improvement.

[MikeBishop]

Looking at the larger paragraph, the point is that there are two possible states when a server decides not to fulfill a push:

a. No stream has been created; CANCEL_PUSH is sufficient.
b. A stream has been created.

1. The server could simply reset the stream; this is valid, but risks the client processing the RESET before learning the Push ID, so it won't know which Push ID is no longer being fulfilled.
2. Better if the server both resets the stream and sends a CANCEL_PUSH.

You're right that this could be reworded to emphasize that you always send CANCEL_PUSH if you're not fulfilling a promise, and also close the stream if you've opened one.