Subject: [quicwg/base-drafts] Truncated http stream error handling is aggressive (#2718)

From: MikkelFJ <[email-masked]>
Date: Thu, 16 May 2019 23:55:05 -0700

HTTP draft sect. 6.1

> These streams carry frames related to the request/response (see Section 4.1). When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error (see HTTP_MALFORMED_FRAME in Section 8.1). 

I can see the point of always sending the header fields of a frame, but if a data frame is required to be sent in full or have the connection closed, it is hard for a server to stop a cancelled request without having the connection closed when it sends an entire file in a single data frame.

Splitting up files into multiple frames ought to be done because the length is not known in advance, not to avoid connection close.

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 May 2019 03:26:14 -0700

If you create a stream that is invalid, then it is perfectly reasonable to kill the connection.  If you make a bad prediction that results in having to abandon a stream, then RESET_STREAM is the tool you use.  You don't close the stream as though it was OK.

-- 
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/2718#issuecomment-493405408

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 17 May 2019 03:38:44 -0700

Right. After thinking this over again, I think @mikkelfj's case falls into the bracket of request cancellation desribed in section 5.1.2 of draft 20.

Someone wants to abruptly finish the request or response, so it is not a clean termination.

-- 
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/2718#issuecomment-493408666

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 May 2019 11:00:18 -0700

I actually encountered this bug in the past, where the server decided to truncate a response but didn't indicate that there was an abort.  Then the truncated response was cached and served to future clients.

If you're not going to finish the response, RESET the stream so everyone knows it.

-- 
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/2718#issuecomment-493544604