Draft: draft-ietf-quic-http

Commentary: Does n't directly reference the http - core text , because , but uses parallel language . Might want to add a reference to as part of . 
 Does it matter if the the STOPSENDING error code is something other than EARLY RESPONSE ? Originally posted by in Moving this out to a separate issue to avoid complicating ; my inclination is to propose the following rules : When a STOPSENDING is received , if the error code has semantics in the context in which you received it , follow the semantics . If the error code has no semantics in that context ( or is unknown ) , then it has no direct effect on the viability of the request or the response . If resetting your request stream causes the server to be unable to generate a response , it will reset its stream . If it sends a complete response , the server clearly got everything it needed ; the response is usable . If a response stream is reset after all bytes have been received , the response remains usable ; no takebacks . 
 Several of these are already in the draft : Perhaps the clarification that 's needed is to keep the " MAY abort reading , " but separately say that " H3EARLYRESPONSE SHOULD be used as the error code " ? ( Which does raise the question of whether it needs to be a separate error code from H3NOERROR .... ) 
 There is a text that say : A server MAY send STOPSENDING . What should the client do if the server does not send it ? Is the client allowed to close the send stream or should it continue until everything has been sent ? In the second case the client may receive the complete response before the complete request has been sent . Is there a use case where a sever can send a response before receiving the complete request , but still cares about the request data ? 
 Good question . From a purely transactional point of view , if no part of the response depends on the remainder of the request , the client might as well stop sending . However , I can also imagine an API where the server wants to consume and store the remainder of what the client is sending even if the return value is determined already . The most generic way to handle this is to say that the server can express that it does n't need the remainder of the response , and if it does n't do so , the client SHOULD finish sending it . 
 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 . 
 Maybe add that blurb . I 'd recommend marking this as editorial on that basis . 
 The text is now : 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 HTTPEARLYRESPONSE , 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 . 
 Discussed in Cupertino ; http - core will or should say that clients have to send the full request . Point to core or clarify . 
 http - core : I think the resolution here is to explicitly map STOPSENDING(EARLYRESPONSE ) 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 . 
 Does it matter if the the STOP_SENDING error code is something other than EARLY RESPONSE ? 
 Some references in HTTP / QUIC would benefit from invoking the HTTPter drafts instead , if they finish before we do . For example , the text is is unnecessarily awkward because it references concepts from RFC 7230 while disclaiming the wire format . The equivalent text in is far more appropriate . 
 I think this should be unparked before last call . 
 The intent was to make the cut - over if the dependency would not delay QUIC . It seems like they 're progressing quickly enough that we could probably do that .
Paragraph (version A):
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
H3_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.
Paragraph (version B):
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 the server does
not need to receive the remainder of the request, it MAY abort
reading the request stream with error code H3_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.  If the server sends
a partial or complete response but does not abort reading, clients
SHOULD continue sending the body of the request and close the stream
normally.