jiebi/CodeConvo huggingface dataset:
Code change:
Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.

Related discussion:
text: A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a <del> single comma (",") and optional whitespace (OWS). </del> <ins> single comma (",") and optional whitespace ( , defined in whitespace). </ins> 5.6.1.1.
Code change:
LGTM.
Need to explain or reference explanation.
LGTM.
okay, I think this reads better, or we can split them into separate PRs if needed

Related discussion:
text: for the <del> . </del> <ins> .  A successful response reflects the quality of "sameness" identified by the target URI (RFC3986).  Hence, retrieving identifiable information via HTTP is usually performed by making a GET request on an identifier associated with the potential for providing that information in a response. </ins> GET is the primary mechanism of information retrieval and the focus <del> of almost all performance optimizations.  Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.  A successful response reflects the quality of "sameness" identified by the target URI.  In turn, constructing applications such that they produce a URI for each important resource results in more resources being available for other applications, producing a network effect that promotes further expansion of the Web. </del> <ins> of almost all performance optimizations.  Applications that produce a URI for each important resource can benefit from those optimizations while enabling their reuse by other applications, creating a network effect that promotes further expansion of the Web. </ins> It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of
Code change:
I'm a little uneasy that the majority of headers that are prefixed with are actually scoped to the selected representation. E.g., , , , . The only registered, current headers that actually about the content (using the current definition in Semantics) are and , AFAICT. Not sure about ; it's defined in terms of the selected representation, but could equally be defined in terms of content, I suspect. It might help to add a small note to the that explains that the prefix doesn't necessarily imply that the header is strictly about the content. Also might be worth mentioning in the .
Reading semantics I have some doubts on C-L wrt partial representation this seems to be the full representation data (eg. see C-L + HEAD). But then what happens with value in a range response? The complete representation-data or the actual content?
"A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation. Each Content-Range header field includes information about the selected representation's complete length." So the case of a 206 response is special-cased.
It seems to me that C-L is more often used to convey "messaging" information, than the actual metadata (which happens only when HEAD is used).

Related discussion:
text: information. Other prefixes are sometimes used in HTTP field names; for example, <del> "Accept-" is used in many content negotiation headers.  These prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. </del> <ins> "Accept-" is used in many content negotiation headers, and "Content-" is used as explained in content.  These prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. </ins> 16.3.2.2.
Code change:
Source:
It's completely irrelevant to the recipient what port number was used for an upstream intermediary, which is why it says MAY here.
There are two issues here: 1) The protocol-name doesn't reflect the scheme in use, for HTTPS, it's still 'HTTP'. The practical implication of that is that when HTTPS is used, the port needs to be explicit, even if it's the default for HTTPS. A clarifying note might help here. 2) HTTP/3 uses UDP, not TCP. Omitting 'TCP' from the MAY requirement might help.
This is for Via. HTTPS is not a separate protocol. "https" is a scheme that, among other things, doesn't allow an intermediary to forward HTTP messages until they are beyond the origin secured connection (and hence no longer HTTP/TLS). Whatever the post-TLS origin does to forward its messages via CDN or downstream origins is beyond the scope here.
Yes, we can just remove TCP from that sentence.
That would be acceptable.

Related discussion:
text: message.  However, if the real host is considered to be sensitive information, a sender MAY replace it with a pseudonym.  If a port is not provided, a recipient MAY interpret that as meaning it was <del> received on the default TCP port, if any, for the received-protocol. </del> <ins> received on the default port, if any, for the received-protocol. </ins> A sender MAY generate comments to identify the software of each recipient, analogous to the
Code change:
says: [...] says about : [...] Because we're saying that validation occurs against all responses for a given URI (see ), this has the effect of allowing a response with a header to update all of the responses sent for that URI in that second (provided the requirement about is met) -- which would lead to e.g., response with updating other languages. That probably isn't desirable. The obvious way to fix this is to avoid promoting to a strong validator when it's being used by a cache. However, see -- it's necessary for it to be strong for . It might also be worth refining caching 3.4.3 to differentiate between entity-tag updates and last-modified updates.
In 4.3.5, updating is done like this: Note that it's specified in terms of responses that could have been selected for that request, rather than "stored... responses for the applicable request URI." If we modified 4.3.4 to specify that responses that could have been selected for the request sent are updated (still subject to further filtering down by any validators in the 304 response), I think it should work.

Related discussion:
text: When a cache receives a <del> response and already has one or more stored </del> <ins> response, it needs to identify stored responses that are suitable for updating with the new information provided, and then do so. </ins> <del> responses for the applicable request URI, the cache needs to identify which (if any) are to be updated by the new information provided, and then do so. </del> <ins> The initial set of stored responses to update are those that could have been selected for that request -- i.e., those that meet the requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated. </ins> <del> The stored response(s) to update are identified by using the first match (if any) of: </del> <ins> Then, that initial set of stored response(s) is further filtered by the first match of: </ins> For each stored response identified, the cache MUST update its header fields with the header fields provided in the
Code change:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Related discussion:
text: 4.1. When a cache receives a request that can be satisfied by a stored <del> response that has a </del> <ins> response and that stored response contains a </ins> <del> header field (field.vary), it MUST NOT use that response unless all the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request. </del> <ins> header field (field.vary), the cache MUST NOT use that stored response without revalidation unless all the selecting header fields (nominated by that Vary field value) in the present request match those fields in the original request (i.e., the request that caused the cached response to be stored). </ins> The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in
Code change:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Related discussion:
text: absent from a request, it can only match another request if it is also absent there. <del> A </del> <ins> A stored response with a </ins> header field value containing a member "*" always fails to match.
Code change:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Related discussion:
text: current_age is defined in age.calculations. Clients can send the max-age or min-fresh request directives (cache- <del> request-directive) to constrain or relax freshness calculations for the corresponding response.  However, caches are not required to </del> <ins> request-directive) to suggest limits on the freshness calculations for the corresponding response.  However, caches are not required to </ins> honor them. When calculating freshness, to avoid common problems in date parsing:
Code change:
replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...

Related discussion:
text: A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: <del> Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server. </del> <ins> Note that this calculation is intended to reduce clock skew by using the clock information provided by the origin server whenever possible. </ins> When there is more than one value present for a given directive (e.g., two
Code change:
This is related to the suggestion in but provides the modern reason why all servers work this way.
'This allows servers to be deployed in non-traditional configurations, such as within a custom service mesh or content distribution network, where the proxy/origin distinction is handled upstream.' I don't really buy this; suggest just removing this sentence.

Related discussion:
text: authority component, an empty Host header field will be sent in this case. <del> To allow for the possibility of a transition to the absolute-form for all requests in some future version of HTTP, a server MUST accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies. </del> <ins> A server MUST accept the absolute-form in requests even though most HTTP/1.1 clients will only send the absolute-form to a proxy. </ins> 3.2.3.
Code change:
…Control (
See URL
I think we might re-visit this advice, since CC is so widely implemented, but the errata is correct, so yes.

Related discussion:
text: pragma and cache-control directives, unless Cache-Control: no-cache is purposefully omitted to target other <del> response directives at HTTP/1.1 caches.  For example: </del> <ins> request directives at HTTP/1.1 caches.  For example: </ins> will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand
Code change:
In semantics 7.7: I found where (in the discussion of normalization in §4.2.3) we say to replace the empty path with "/" for non-OPTIONS requests. I couldn't find anywhere "above" where it was noted to replace an empty path with "*" (presumably, for the OPTIONS requests), though.
This is a reference to text that was moved to HTTP/1.1 because it is version specific. I suggest we replace it with
LGTM

Related discussion:
text: host name if the target URI contains a fully qualified domain name. A proxy MUST NOT modify the "absolute-path" and "query" parts of the <del> received target URI when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*". </del> <ins> received target URI when forwarding it to the next inbound server except as required by that forwarding protocol.  For example, a proxy forwarding a request to an origin server via HTTP/1.1 will replace an empty path with "/" (origin-form) or "*" (asterisk-form), depending on the request method. </ins> A proxy MUST NOT transform the content (content) of a message that contains a no-transform cache-control response directive
Code change:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Related discussion:
text: 10.1.5. <del> The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated metadata before it starts processing the content. For example, a sender might indicate that a signature will be computed as the content is being streamed and provide the final signature as a trailer field.  This allows a recipient to perform the same check on the fly as it receives the content. A sender that intends to generate one or more trailer fields in a message SHOULD generate a header field in the header section of that message to indicate which fields might be present in the trailers. If an intermediary discards the trailer section in transit, the field could provide a hint of what metadata was lost, though there is no guarantee that a sender of Trailer will always follow through by sending the named fields. 10.1.6. </del> The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work
Code change:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Related discussion:
text: 10.2.2. <del> The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in RFC5322.  The field value is an HTTP-date, as defined in http.date. An example is A sender that generates a Date header field SHOULD generate its field value as the best available approximation of the date and time of message generation.  In theory, the date ought to represent the moment just before generating the message content.  In practice, a sender can generate the date value at any time during message origination. An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instant in Coordinated Universal Time.  An origin server MAY send a Date header field if the response is in the or class of status codes.  An origin server MUST send a Date header field in all other cases. A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream. A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received. A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server.  For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks. 10.2.3. </del> The "Location" header field is used in some responses to refer to a specific resource in relation to the response.  The type of relationship is defined by the combination of request method and
Code change:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Related discussion:
text: response is supposed to provide a URI that is specific to the created resource. <del> 10.2.4. </del> <ins> 10.2.3. </ins> Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request.  When
Code change:
This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho

Related discussion:
text: In the latter example, the delay is 2 minutes. <del> 10.2.5. </del> <ins> 10.2.4. </ins> The "Server" header field contains information about the software used by the origin server to handle the request, which is often used
Code change:
Note that this also rephrases the SHOULD requirement, but doesn't change its effect.
As mentioned in ... >Section 12.5.5

Related discussion:
text: 12.5.5. The "Vary" header field in a response describes what parts of a <del> request message, aside from the method and target URI, might influence the origin server's process for selecting and representing </del> <ins> request message, aside from the method and target URI, might have influenced the origin server's process for selecting the content of </ins> this response. <del> A Vary field value is a list of request field names, known as the selecting header fields, that might have a role in selecting the representation for this response.  Potential selecting header fields are not limited to those defined by this specification. </del> <ins> A Vary field value is either the wildcard member "*" or a list of request field names, known as the selecting header fields, that might have had a role in selecting the representation for this response. Potential selecting header fields are not limited to fields defined by this specification. </ins> <del> If the list contains "*", it signals that other aspects of the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </del> <ins> A list containing the member "*" signals that other aspects of the request might have played a role in selecting the response representation, possibly including aspects outside the message syntax (e.g., the client's network address).  A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server.  A proxy MUST NOT generate "*" in a Vary field value. </ins> For example, a response that contains