jiebi/CodeConvo huggingface dataset:
Code change:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Related discussion:
text: requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a <del> cache MUST use the header fields provided in the new response, aside from , to replace all instances of the corresponding header fields in the stored response. </del> <ins> cache MUST update the stored response header fields using the header fields provided in the new response, as per update. </ins> 4.
Code change:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Related discussion:
text: The stored response(s) to update are identified by using the first match (if any) of: <del> For each stored response identified for update, the cache MUST use the header fields provided in the response to replace all instances of the corresponding header fields in the stored response, with the following exceptions: In some cases, caches (especially in user agents) store processed representations of the received response, rather than the response itself, and updating header fields that affect that processing can result in inconsistent behavior and security issues.  Caches in this situation MAY omit these header fields from updating stored representations on an exceptional basis, but SHOULD limit such omission to those fields necessary to assure integrity of the stored representation. For example, a browser might store a response's body after removing content-codings, thereby making its metadata inaccurate.  Updating that stored metadata with a different Content-Encoding header field would be problematic.  Likewise, a browser might store a post-parse tree representation of HTML, rather than the body received in the response; updating the Content-Type header field would not be workable in this case, because any assumptions about the format made in parsing would now be invalid. Furthermore, some fields are automatically processed and removed by the HTTP implementation; for example, the Content-Range header field. Implementations MAY automatically omit such header fields from updates, even when the processing does not actually occur. </del> <ins> For each stored response identified, the cache MUST update its header fields with the header fields provided in the </ins> <del> Note that the Content-* prefix is not a signal that a header field is omitted from update; it is only a convention for naming content- related fields. </del> <ins> response, as per update. </ins> 4.3.5.
Code change:
Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.

Related discussion:
text: If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST use the header fields provided in the <del> HEAD response to replace all instances of the corresponding header fields in the stored response (subject to the exceptions in freshening.responses) and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del> <ins> HEAD response to update the stored response (see update). </ins> 4.4.
Code change:
"The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.

Related discussion:
text: collected.abnf shows the collected grammar with all list operators expanded to standard ABNF notation. <del> The following core rules are included by reference, as defined in RFC5234: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible USASCII character). </del> <ins> The following core rule is included by reference, as defined in RFC5234: DIGIT (decimal 0-9). </ins> Semantics defines the following rules:
Code change:
"The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible [USASCII] character)." Of these, only DIGIT is actually used.

Related discussion:
text: G Grammar <del> ALPHA CR CRLF CTL </del> DIGIT <del> DQUOTE HEXDIG HTAB LF OCTET SP VCHAR </del> H Header Fields
Code change:
seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.

Related discussion:
text: feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms. <del> 3.6. </del> Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI.  In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O). <del> The following example illustrates a typical message exchange for a GET request (GET) on the URI "http://www.example.com/hello.txt": Client request: Server response: 3.7. </del> <ins> 3.6. </ins> HTTP enables the use of intermediaries to satisfy requests through a chain of connections.  There are three common forms of HTTP
Code change:
seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.

Related discussion:
text: RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. <del> 3.8. </del> <ins> 3.7. </ins> A "
Code change:
seems very out of place. I could almost see it as content in 3, as a kind of introduction to the terminology. There are of course other places it could go, but the current location doesn't make much sense.
I moved the ascii art diagram back to the origin server section (where it came from in 7230) since it leads into the other diagrams.

Related discussion:
text: multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on. <ins> 3.8. The following example illustrates a typical HTTP/1.1 message exchange for a GET request (GET) on the URI "http://www.example.com/ hello.txt": Client request: Server response: </ins> 4. Uniform Resource Identifiers (URIs) RFC3986 are used throughout HTTP
Code change:
As discussed on call, we need to say that PUT requests can contain response headers, and what that means.

Related discussion:
text: response to indicate successful completion of the request. <del> An origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., do not save them as part of the resource state). </del> An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT.  This is
Code change:
As discussed on call, we need to say that PUT requests can contain response headers, and what that means.

Related discussion:
text: all implementation details behind the resource interface are intentionally hidden by the server. <ins> This extends to how header and trailer fields are stored; while common header fields like will typically be stored and returned upon subsequent GET requests, header and trailer field handling is specific to the resource that received the request.  As a result, an origin server SHOULD ignore unrecognized header and trailer fields received in a PUT request (i.e., do not save them as part of the resource state). </ins> An origin server MUST NOT send a validator field (response.validator), such as an
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload <del> body.  A recipient of such a bare CR MUST consider that element to be </del> <ins> data.  A recipient of such a bare CR MUST consider that element to be </ins> invalid or replace each bare CR with SP before processing the element or forwarding the message.
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: 6. <del> The message body (if any) of an HTTP message is used to carry the payload body (payload.body) of that request or response.  The message body is identical to the payload body unless a transfer coding has been applied, as described in field.transfer-encoding. </del> <ins> The message body (if any) of an HTTP/1.1 message is used to carry payload data (payload) for the request or response.  The message body is identical to the payload data unless a transfer coding has been applied, as described in field.transfer-encoding. </ins> The rules for determining when a message body is present in an HTTP/1.1 message differ for requests and responses.
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: or header field.  Request message framing is independent of method <del> semantics, even if the method does not define any use for a message body. </del> <ins> semantics. </ins> The presence of a message body in a response depends on both the request method to which it is responding and the response status code <del> (status.line), and corresponds to when a payload body is allowed; see payload.body. </del> <ins> (status.line), and corresponds to when payload data is allowed; see payload. </ins> 6.1. The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or <del> will be) applied to the payload body in order to form the message </del> <ins> will be) applied to the payload data in order to form the message </ins> body.  Transfer codings are defined in transfer.codings. Transfer-Encoding is analogous to the Content-Transfer-Encoding field
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: A recipient MUST be able to parse the chunked transfer coding (chunked.encoding) because it plays a crucial role in framing <del> messages when the payload body size is not known in advance.  A </del> <ins> messages when the payload data size is not known in advance.  A </ins> sender MUST NOT apply chunked more than once to a message body (i.e., chunking an already chunked message is not allowed).  If any transfer <del> coding other than chunked is applied to a request payload body, the </del> <ins> coding other than chunked is applied to a request's payload data, the </ins> sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed.  If any transfer coding other than <del> chunked is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </del> <ins> chunked is applied to a response's payload data, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection. </ins> For example, <del> indicates that the payload body has been compressed using the gzip </del> <ins> indicates that the payload data has been compressed using the gzip </ins> coding and then chunked using the chunked coding while forming the message body.
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: When a message does not have a header field, a Content-Length header field can provide the <del> anticipated size, as a decimal number of octets, for a potential payload body.  For messages that do include a payload body, the </del> <ins> anticipated size, as a decimal number of octets, for potential payload data.  For messages that do include payload data, the </ins> Content-Length field value provides the framing information necessary <del> for determining where the body (and message) ends.  For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (field.content-length). </del> <ins> for determining where the data (and message) ends.  For messages that do not include payload data, the Content-Length indicates the size of the selected representation (field.content-length). </ins> 6.3.
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: If the final response to the last request on a connection has been completely received and there remains additional data to read, a user agent MAY discard the remaining data or attempt to determine if that <del> data belongs as part of the prior response body, which might be the </del> <ins> data belongs as part of the prior message body, which might be the </ins> case if the prior message's Content-Length value is incorrect.  A client MUST NOT process, cache, or forward such extra data as a separate response, since such behavior would be vulnerable to cache
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: 7. Transfer coding names are used to indicate an encoding transformation <del> that has been, can be, or might need to be applied to a payload body in order to ensure "safe transport" through the network.  This </del> <ins> that has been, can be, or might need to be applied to a payload's data in order to ensure "safe transport" through the network.  This </ins> differs from a content coding in that the transfer coding is a property of the message rather than a property of the representation that is being transferred. <del> Parameters are in the form of a name=value pair. </del> All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined in transfer.coding.registry.  They are used in the <del> (field.te) and </del> <ins> (field.transfer-encoding) and </ins> <del> (field.transfer-encoding) header fields. </del> <ins> (field.te) header fields (the latter also defining the "transfer- coding" grammar). </ins> 7.1. <del> The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </del> <ins> The chunked transfer coding wraps payload data in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields.  Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </ins> retain connection persistence and the recipient to know when it has received the entire message.
Code change:
I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?

Related discussion:
text: A trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might <del> be dynamically generated while the message body is sent, such as a </del> <ins> be dynamically generated while the payload data is sent, such as a </ins> message integrity check, digital signature, or post-processing status.  The proper use and limitations of trailer fields are defined in trailer.fields.