jiebi/CodeConvo huggingface dataset:
Code change:
NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?

Related discussion:
text: source code and issues list for this draft can be found at <https://github.com/httpwg/http-core>. <del> The changes in this draft are summarized in changes.since.04. </del> <ins> The changes in this draft are summarized in changes.since.05. </ins> 1.
Code change:
NAME yes, as per issue discussion I was reconsidering this. See updated PR.
yeah, I like that. Will update.
It'd be good to say something about how weakly-framed content (e.g., no Content-Length in 1.0; no CL or chunked in 1.1) should be handled differently by caches, especially during reload. From URL
In , add:
currently has: Observations: the reference really should be more specific and go to "6.3. Message Body Length" is this clear enough for protocols other than HTTP/1.1?
Referring to h1-messaging 6.3 would make this specific to H1. Referring to 4.3.1 in caching keeps it protocol-generic. If another version doesn't crisply define what's an incomplete message, we can deal with that separately.
I think the text in 3.1 should change to:
This seems reasonable. It's also related to URL, asking whether servers can wait for end-of-stream to consider a message complete in HTTP/3. (Proposal in URL is "no, you can't.")
No, HTTP/1.0 is consistently optimistic. If the server desires more rigor, it can do the work to supply the framing that would indicate an error occurred. When it fails to do so, it is deliberately choosing to maximize performance over correctness. Hence, the assumption has always been that a close-delimited message is always complete.
I think Mark's suggestion is right. I would characterize HTTP/1.0 as ambiguous and that causes revalidation deadlocks. Its somewhat worse that this pattern needlessly shows up in HTTP/1.1 as well.
Thinking on this for a while, I think MAY might be more appropriate than SHOULD here; I have a strong suspicion that most caches will not consider a close-delimited response as incomplete. I could test it, I suppose.
Also, in the sentence: ...I think s/partial/incomplete/, based on context. Any concerns there?

Related discussion:
text: 3.1. A response message is considered complete when all of the octets <del> indicated by the message framing (Messaging) are received prior to the connection being closed.  If the request method is GET, the response status code is </del> <ins> indicated by its framing are available.  Note that this includes a message that is ended by the connection's close (see Messaging). Although caches are encouraged to consider such a response incomplete when the connection termination was irregular, that is not always possible to detect; therefore, servers wishing to avoid caching of partial responses due to connection termination will need to use explicit framing. If the request method is GET, the response status code is </ins> , and the entire response header section has been received, a cache MAY store an incomplete response message body if the cache entry is
Code change:
…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.

Related discussion:
text: the request will have the same intended effect, even if the original request succeeded, though the response might differ. <ins> A user agent MUST NOT automatically retry a request with a non- idempotent method unless it has some means to know that the request semantics are actually idempotent, regardless of the method, or some means to detect that the original request was never applied.  For example, a user agent that knows (through design or configuration) that a POST request to a given resource is safe can repeat that request automatically.  Likewise, a user agent designed specifically to operate on a version control repository might be able to recover from partial failure conditions by checking the target resource revision(s) after a failed connection, reverting or fixing any changes that were partially applied, and then automatically retrying the requests that failed. A proxy MUST NOT automatically retry non-idempotent requests. A client SHOULD NOT automatically retry a failed automatic retry. </ins> 7.2.3. Request methods can be defined as "
Code change:
…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.

Related discussion:
text: 9.5.20. <del> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a </del> <ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a </ins> <del> status code is inappropriate), and the syntax of the request entity is correct but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body </del> <ins> status code is inappropriate), and the syntax of the request payload is correct, but was unable to process the contained instructions. For example, this status code can be sent if an XML request payload </ins> contains well-formed (i.e., syntactically correct), but semantically <del> erroneous, XML instructions. </del> <ins> erroneous XML instructions. </ins> 9.5.21.
Code change:
…se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.

Related discussion:
text: 416 Range Not Satisfiable (status code) 417 Expectation Failed (status code) 418 (Unused) (status code) <del> 422 Unprocessable Entity (status code) </del> <ins> 422 Unprocessable Payload (status code) </ins> 426 Upgrade Required (status code) 4xx Client Error (status code class)
Code change:
: That is incorrect, as the status code could be 204, or the response might come with chunked encoding (even when empty). This is .
What purpose is this requirement serving? It seems to have the effect of prohibiting with a zero length payload. Shouldn't RFC 7230, "3.3.3. Message Body Length" be sufficient for determining payload sizes?
Agreed. The text makes it sound as if OPTIONS is somehow special. Giving advice might be good, but the use of normative keywords makes this confusing. The simplest fix might indeed be to remove the sentence.
LGTM

Related discussion:
text: The response payload, if any, might also describe the communication options in a machine or human-readable representation.  A standard format for such a representation is not defined by this <del> specification, but might be defined by future extensions to HTTP.  A server MUST generate a field with a value of "0" if no payload body is to be sent in the response. </del> <ins> specification, but might be defined by future extensions to HTTP. </ins> A client MAY send a
Code change:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Related discussion:
text: explicit expiration time is present in the stored response.  Because of the requirements in response.cacheability, this means that, effectively, heuristics can only be used on responses without <del> explicit freshness whose status codes are defined as cacheable by default (see overview.of.status.codes), and those responses without </del> <ins> explicit freshness whose status codes are defined as " " (e.g., see overview.of.status.codes), and those responses without </ins> explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive). <ins> Note that in previous specifications heuristically cacheable response status codes were called "cacheable by default." </ins> If the response has a header field (header.last-modified), caches are encouraged to use a
Code change:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Related discussion:
text: , and response.cacheability for details of how public affects responses that would normally not be stored, due to their status <del> codes not being defined as cacheable by default; see </del> <ins> codes not being defined as heuristically cacheable; see </ins> heuristic.freshness.) 5.2.2.6.
Code change:
For .
NAME it didn't so much introduce it as much as it just changed the nature of the example.
Well, before the term "timing attack" did not appear in the spec...
... needs a rewrite. I'm thinking of splitting up into distinct sections, e.g., Cache Poisoning Timing Attacks Caching of Sensitive Information Information Leakage ... with appropriate mitigations in each (e.g., double keying).
This also adds "Timing Attacks", right. Updated change log as well.

Related discussion:
text: H heuristic expiration time <ins> heuristically cacheable </ins> M max-age (cache directive)
Code change:
As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.

Related discussion:
text: 2.1. <del> All HTTP/1.1 messages consist of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format RFC5322: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. An HTTP message can be either a request from client to server or a response from server to client.  Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (message.body). </del> <ins> An HTTP/1.1 message consists of a start-line followed by a CRLF and a sequence of octets in a format similar to the Internet Message Format RFC5322: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating the end of the header section, and an optional message body. A message can be either a request from client to server or a response from server to client.  Syntactically, the two types of message differ only in the start-line, which is either a request-line (for requests) or a status-line (for responses), and in the algorithm for determining the length of the message body (message.body). </ins> In theory, a client could receive requests and a server could receive responses, distinguishing them by their different start-line formats.
Code change:
As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.

Related discussion:
text: Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from <del> asynchronous close events. When an inbound connection is closed prematurely, a client MAY open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent methods (idempotent.methods). </del> <ins> asynchronous close events.  The conditions under which a client can automatically retry a sequence of outstanding requests are defined in idempotent.methods. </ins> 9.4.2.
Code change:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Related discussion:
text: non-public content, or poison a cache.  See security.considerations for security considerations regarding message routing. <del> 5.4. </del> <ins> 5.5. </ins> The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to
Code change:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Related discussion:
text: field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value. <del> 5.5. </del> <ins> 5.6. </ins> As described in intermediaries, intermediaries can serve a variety of roles in the processing of HTTP requests and responses.  Some
Code change:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Related discussion:
text: will buffer or delay message forwarding for the sake of network efficiency, security checks, or payload transformations. <del> 5.5.1. </del> <ins> 5.6.1. </ins> The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on
Code change:
and with the hope of being useful for quicwg/base-drafts I suspect that we also need to move "Initiating HTTP over TLS" down to the section on Routing, but that can be done separately.
This is now ready to merge, IMO. There is more work to do after merging, specifically taking the old RFC2818 description of initiating HTTP over TLS out and moving just the 1.1-specific bits to Messaging, but I don't want to do that in the same PR.
I agree with Roy. This is big enough that merging and iterating is the right path.
From :
Looks good enough to merge and iterate upon. Will need change notes, of course.

Related discussion:
text: replaced by pseudonyms.  A sender MUST NOT combine entries that have different received-protocol values. <del> 5.5.2. </del> <ins> 5.6.2. </ins> Some intermediaries include features for transforming messages and their payloads.  A proxy might, for example, convert between image
Code change:
pasted twice, second should have been s-maxage
The commit d4695a3e422f677d880dc64504c492bf71b6039d for added a paragraph to s-maxage that contains the directive must-revalidate. I think this was supposed to say s-maxage and worded for shared caches?
Sorry, been travelling. This was intentional (although I forgot to update the directive name). implies , which implies . That seems like a lot of indirection in the definition. I agree this wasn't a great way to do it, though. I think the options are: Leave it as is (i.e., two levels of indirection). Leave it as is, but use linking more explicitly so that the indirections can be followed more easily (at least in HTML renderings). Inline the appropriate text from into both and . I think those are ordered according to my preferences, least to most. (I strongly suspect many people don't realise has these semantics, because of it having a name similar to . Making them inline rather than referenced might help)
I agree with the conclusion, but am pretty sure that you meant to say s-maxage in that section defining s-maxage. That's all I changed, so it should be fine unless you wanted to add more text to explain why. I don't think it is necessary to explain more because adding s-maxage implies the server wants shared caches to reuse the response.
I agree with NAME that the additional semantics of are surprising. In particular due to section 4.2.1, comes disguised as the "different value for shared caches". So , and the difference is the handling of error cases like with ? Could you please try to explain why the additional semantics of make sense – that is, why did you not just make it the alternative TTL for shred caches? Thank you!
Ah, okay, so the added paragraph had the right directive before but simply doesn’t make any sense given the context.

Related discussion:
text: header field.  The s-maxage directive also implies the semantics of the proxy-revalidate response directive. <del> The must-revalidate directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </del> <ins> The s-maxage directive also has the effect of allowing a stored response to be used to satisfy a request with an Authorization header field; see caching.authenticated.responses. </ins> This directive uses the token form of the argument syntax: e.g., 's-maxage=10' not 's-maxage="10"'.  A sender SHOULD NOT generate the