Specify behavior on incomplete requests #1643
Conversation
MikeBishop
added
design
draft-ietf-quic-http.md
Outdated
| discard responses at their discretion for other reasons. | ||
|
|
||
| Servers MUST NOT abort a response in progress as a result of receiving a | ||
| solicited RST_STREAM (i.e. with error code STOPPING). If the request stream |
There was a problem hiding this comment.
missing comma after "i.e."
draft-ietf-quic-http.md
Outdated
| abort a response in progress as a result of receiving a solicited RST_STREAM. | ||
| discard responses at their discretion for other reasons. | ||
|
|
||
| Servers MUST NOT abort a response in progress as a result of receiving a |
There was a problem hiding this comment.
Perhaps the way to do this is to say:
Cancellation of a request stream does not prevent a server from sending a response. A client that does not want a response SHOULD send a STOP_SENDING frame. A server does not need to take receipt of a RST_STREAM as a signal that it cannot provide a response, though it might be unable to do so. If a stream is reset by the client and the server is unable to respond as a result, it can treat that as a stream error of type HTTP_INCOMPLETE_REQUEST.
This is a different structure - it says that any STOP_SENDING and RST_STREAM on the request side of a stream only cancel the request and not the response. But I think that this is neater - it avoids all of the coupling you have going on here.
There was a problem hiding this comment.
I think that's basically what I was going for (the error at the server is that it doesn't have a complete request, not that the RST occurred), but that's a clearer way to state it.
draft-ietf-quic-http.md
Outdated
| (regardless of error code), do not affect the state of the server's response. | ||
| Servers MUST NOT abort a response in progress solely due to a state change on | ||
| the request stream. However, if the request stream terminates without containing | ||
| a fully-formed HTTP request, the server SHOULD abort its response with the error |
There was a problem hiding this comment.
s/fully-formed/usable/ perhaps.
A server can often produce a response based purely on header fields. That's the case that we specifically want to support with STOP_SENDING (a 404 on a POST). This implies that the message needs to be complete, which isn't necessary.
draft-ietf-quic-http.md
Outdated
|
|
||
| Changes to the state of a request stream, including receiving a RST_STREAM | ||
| (regardless of error code), do not affect the state of the server's response. | ||
| Servers MUST NOT abort a response in progress solely due to a state change on |
There was a problem hiding this comment.
I don't think that this is a normative requirement on reflection. Maybe just "Servers do not abort a response..." or "Servers are not expected to abort a response..."
draft-ietf-quic-http.md
Outdated
| discard responses at their discretion for other reasons. | ||
|
|
||
| Changes to the state of a request stream, including receiving a RST_STREAM | ||
| (regardless of error code), do not affect the state of the server's response. |
There was a problem hiding this comment.
s/(regardless of error code)/with any error code/
Fixes #1596 (and an oversight I caught in passing) by specifying server behavior if it reaches the end of readable data on a stream and hasn't parsed a full HTTP request yet. There are a couple cases here, and I think this generically covers all the interesting ones.
We already discuss cancelling requests, so I added a suggestion that clients go ahead and include a STOP_SENDING if they reset their request stream.