Subject: Re: [quicwg/base-drafts] What if server does not send HTTP_EARLY_RESPONSE but starts sending response (#2963)

From: Mike Bishop <[email-masked]>
Date: Mon, 07 Oct 2019 10:32:13 -0700

Another potential case where the server would want to keep the client sending is where the server is performing some transformation (compress/decompress, transcode, en/decrypt, etc.) on the data sent by the client, and is doing the conversion in blocks as bytes are received rather than storing the full resource locally.

The same recommendation stands -- unless the server exercises the option to tell the client to stop, the usual rules apply that the client needs to fully send the request to get a full response.  Do we need text for this?  I'd think that's already the default position.

-- 
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/2963#issuecomment-539121050

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2019 12:34:41 -0700

Maybe add that blurb.  I'd recommend marking this as editorial on that basis.

-- 
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/2963#issuecomment-542370402

---

From: ianswett <[email-masked]>
Date: Tue, 15 Oct 2019 12:36:00 -0700

The text is now:

> A server can send a complete response prior to the client sending an
   entire request if the response does not depend on any portion of the
   request that has not been sent and received.  When this is true, a
   server MAY abort reading the request stream with error code
   HTTP_EARLY_RESPONSE, send a complete response, and cleanly close the
   sending part of the stream.  Clients MUST NOT discard complete
   responses as a result of having their request terminated abruptly,
   though clients can always discard responses at their discretion for
   other reasons.

-- 
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/2963#issuecomment-542370874

---

From: Mike Bishop <[email-masked]>
Date: Thu, 17 Oct 2019 14:49:50 -0700

Discussed in Cupertino; http-core will or should say that clients have to send the full request.  Point to core or clarify.

-- 
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/2963#issuecomment-543376200

---

From: Mike Bishop <[email-masked]>
Date: Fri, 18 Oct 2019 11:11:31 -0700

http-core [says](https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#header.expect):
> A server that responds with a final status code before reading the entire request payload body SHOULD indicate whether it intends to close the connection (see Section 9.7 of [Messaging]) or continue reading the payload body. 

I think the resolution here is to explicitly map STOP_SENDING(EARLY_RESPONSE) to the indication that it intends the stream to be fully closed after the response, and the absence of STOP_SENDING to the server's intent to continue reading the payload body.

-- 
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/2963#issuecomment-543867377

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 18 Oct 2019 11:44:49 -0700

Does it matter if the the STOP_SENDING error code is something other than EARLY RESPONSE?

-- 
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/2963#issuecomment-543883212

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Oct 2019 13:09:20 -0700

Closed #2963 via #3123.

-- 
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/2963#event-2738406993