jiebi/CodeConvo huggingface dataset:
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: header fields (or lack thereof) as determining factors while choosing the content for this response. <del> An origin server might send Vary with a list of header fields for two purposes: An origin server SHOULD send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and target URI, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency.  For example, there is no need to send the Authorization field name in Vary because reuse across users is constrained by the field definition (field.authorization).  Likewise, an origin server might use Cache- Control response directives (field.cache-control) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching. </del> <ins> A Vary field containing selecting field names has two purposes: An origin server SHOULD generate a Vary header field on a cacheable response when it wishes that response to be selectively reused for subsequent requests.  Generally, that is the case when the response content has been tailored to better fit the preferences expressed by those selecting header fields, such as when an origin server has selected the response's language based on the request's header field. Vary might be elided when an origin server considers variance in content selection to be less significant than Vary's performance impact on caching, particularly when such variance is already being limited by Cache-Control response directives (field.cache-control). Cached content selection is only improved by Vary if there is some chance that the origin server's selection algorithm might prefer a different representation for the recipient in a subsequent request. For example, there is no need to send the Authorization field name in Vary because reuse of that response for a different user is prohibited by the field definition (field.authorization).  Likewise, if the response content has been selected by network region but the origin server wants the cached response to be reused even if recipients move from one region to another, then there is no need for the origin server to indicate such variance in Vary. </ins> 13.
Code change:
From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).

Related discussion:
text: more than one member, or if the request method is neither GET nor HEAD. <ins> A recipient MUST ignore the If-Modified-Since header field if the resource does not have a modification date available. </ins> A recipient MUST interpret an If-Modified-Since field value's timestamp in terms of the origin server's clock.
Code change:
From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).

Related discussion:
text: received field value is not a valid HTTP-date (including when the field value appears to be a list of dates). <ins> A recipient MUST ignore the If-Unmodified-Since header field if the resource does not have a modification date available. </ins> A recipient MUST interpret an If-Unmodified-Since field value's timestamp in terms of the origin server's clock.
Code change:
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.

Related discussion:
text: When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by resolving the host identifier to an IP address, establishing a TCP connection to <del> that address on the indicated port, and sending an HTTP request message to the server containing the URI's identifying data. </del> <ins> that address on the indicated port, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (target.resource). </ins> If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is
Code change:
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.

Related discussion:
text: host identifier to an IP address, establishing a TCP connection to that address on the indicated port, securing the connection end-to- end by successfully initiating TLS over TCP with confidentiality and <del> integrity protection, and sending an HTTP request message over that connection containing the URI's identifying data. </del> <ins> integrity protection, and sending over that connection an HTTP request message containing a request target that matches the client's target URI (target.resource). </ins> If the server responds to such a request with a non-interim HTTP response message, as described in status.codes, then that response is
Code change:
In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.

Related discussion:
text: used to satisfy the request.  Proxy configuration is implementation- dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually <del> identified by an "http" or "https" URI.  If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. </del> <ins> identified by an "http" or "https" URI. If an "http" or "https" proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy and then sending it an HTTP request message containing a request target that matches the client's target URI. </ins> 7.3.3. If no proxy is applicable, a typical client will invoke a handler <del> routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource.  How that is accomplished is dependent on the target URI scheme and defined by its associated specification. </del> <ins> routine (specific to the target URI's scheme) to obtain access to the identified resource.  How that is accomplished is dependent on the target URI scheme and defined by its associated specification. http.origin defines how to obtain access to an "http" resource by establishing (or reusing) an inbound connection to the identified origin server and then sending it an HTTP request message containing a request target that matches the client's target URI. https.origin defines how to obtain access to an "https" resource by establishing (or reusing) an inbound secured connection to an origin server that is authoritative for the identified origin and then sending it an HTTP request message containing a request target that matches the client's target URI. </ins> 7.4.
Code change:
For
Registration requests consist of at least the following information: [...] Specification document(s): Reference to the document that specifies the field, preferably If the registration consists of "at least" a group of information that includes a specification document, doesn't that mean the policy is always "Specification Required", not just for permanent registrations?
I think the intent here was to encourage but not require a specification for provisional registration. Will PR.

Related discussion:
text: (appointed by the IESG or their delegate).  Fields with the status 'permanent' are Specification Required (RFC8126). <del> Registration requests consist of at least the following information: </del> <ins> Registration requests consist of the following information: </ins> And, optionally:
Code change:
This goes back to URL
Simplest possible fix would be to mark it as allowed in trailers as well.

Related discussion:
text: configuration, it will appear as if Proxy-Authentication-Info is being forwarded because each proxy will send the same field value. <ins> Proxy-Authentication-Info can be sent as a trailer field (trailer.fields) when the authentication scheme explicitly allows this. </ins> 12. When responses convey content, whether indicating a success or an
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: header field value containing a member "*" always fails to match. <del> The stored response with matching selecting header fields is known as the . If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use.  When a selecting header field has a known mechanism for doing so (e.g., qvalues on </del> <ins> If multiple stored responses match the selecting header fields (potentially including responses without a Vary header field), the cache will need to choose one to use.  When a selecting header field has a known mechanism for ranking preference (e.g., qvalues on </ins> and similar request header fields), that mechanism MAY be used to <del> select a preferred response.  If such a mechanism is not available, </del> <ins> choose a preferred response.  If such a mechanism is not available, </ins> or leads to equally preferred responses, the most recent response (as determined by the <del> header field) is used, as per constructing.responses.from.caches. </del> <ins> header field) is chosen, as per constructing.responses.from.caches. </ins> Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), with the effect of selecting it for requests to that resource even when more preferable responses are available.  When a <del> cache has multiple responses for a target URI and one or more omits the Vary header field, it SHOULD use the most recent (see age.calculations) valid Vary field value available to select an appropriate response for the request. </del> <ins> cache has multiple stored responses for a target URI and one or more omits the Vary header field, the cache SHOULD choose the most recent see age.calculations) stored response with a valid Vary field value. </ins> <del> If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server in a (possibly conditional; see validation.model) request. </del> <ins> If no stored response matches, the cache cannot satisfy the presented request.  Typically, the request is forwarded to the origin server, potentially with preconditions added to describe what responses the cache has already stored (validation.model). </ins> 4.2.
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not fresh, or <del> one cannot be selected; see caching.negotiated.responses), it can use </del> <ins> one cannot be chosen; see caching.negotiated.responses), it can use </ins> the conditional request mechanism (preconditions) in the forwarded <del> request to give the next inbound server an opportunity to select a </del> <ins> request to give the next inbound server an opportunity to choose a </ins> valid stored response to use, updating the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: response, as per constructing.responses.from.caches, the cache SHOULD evaluate any applicable conditional header field preconditions received in that request with respect to the corresponding validators <del> contained within the selected response. </del> <ins> contained within the stored response. </ins> A cache MUST NOT evaluate conditional header fields that only apply to an origin server, occur in a request with semantics that cannot be
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: header field (field.if-none-match) indicates that the client wants to validate one or more of its own stored responses in comparison to the <del> stored response selected by the cache (as per </del> <ins> stored response chosen by the cache (as per </ins> constructing.responses.from.caches). If an
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: header field and the <del> header field is not present in a selected stored response, a cache SHOULD use the stored response's </del> <ins> header field is not present in a stored response, a cache SHOULD use the stored response's </ins> field value (or, if no Date field is present, the time that the stored response was received) to evaluate the conditional.
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: A cache that implements partial responses to range requests, as defined in field.range, also needs to evaluate a received <del> header field (field.if-range) regarding its selected stored response. </del> <ins> header field (field.if-range) with respect to the cache's chosen response. </ins> When a cache decides to forward a request to revalidate its own stored responses for a request that contains an
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: updating with the new information provided, and then do so. The initial set of stored responses to update are those that could <del> have been selected for that request -- i.e., those that meet the </del> <ins> have been chosen for that request -- i.e., those that meet the </ins> requirements in constructing.responses.from.caches, except the last requirement to be fresh, able to be served stale or just validated.
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: receives a response, the cache SHOULD update or invalidate each of its stored <del> GET responses that could have been selected for that request (see </del> <ins> GET responses that could have been chosen for that request (see </ins> caching.negotiated.responses). <del> For each of the stored responses that could have been selected, if the stored response and HEAD response have matching values for any </del> <ins> For each of the stored responses that could have been chosen, if the stored response and HEAD response have matching values for any </ins> received validator fields ( and
Code change:
Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .

Related discussion:
text: S s-maxage (cache directive) <del> selected response </del> shared cache stale
Code change:
… (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.

Related discussion:
text: 5.2. <del> Historically, HTTP field line values could be extended over multiple </del> <ins> Historically, HTTP/1.x field values could be extended over multiple </ins> lines by preceding each extra line with at least one space or horizontal tab (obs-fold).  This specification deprecates such line folding except within the message/http media type