STOP_SENDING before stream open

[mikkelfj]

Draft says STOP_SENDING can be sent in any state. But what should the stream initiator do with a STOP_SENDING frame send for a stream far out in the future? It could ignore, which makes sense for pointless requests, but a peer that expects to receive data on a (possible uni-directional) stream may want to close a stream ASAP in anticipation of future flow.

If this is not clearly specified, or at least referred to as APP protocol defined, then strange behaviors could emerge.

One use case is reverse proxy receiving auth on one stream and data on another. It forwards the data and sends auth status on another stream. The peer realized credentials won't let the request do anything useful and issues a STOP_SENDING. If the request isn't stopped, the peer could be flooded with large volumes of data that just has to be dropped. If it is arbitrary what happens with a STOP_SENDING before the stream has been created, the flow cannot be stopped reliably. Or, there is the default stream max, but that is intentially large to deal with large valid data volumes.

[martinthomson]

Yes, we should prohibit the frame for streams that are not yet created.

[martinthomson]

Taking this for myself. Add prohibition to the stream state machine section, as well as the frame description.