jiebi/CodeConvo huggingface dataset:
Code change:
I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)

Related discussion:
text: 5.2.2.6. <del> The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.  (See caching.authenticated.responses for additional details related to the use of public in response to a request containing </del> <ins> The "public" response directive overrides certain conditions that would otherwise make a cache unable to store the response. Specifically, see caching.authenticated.responses regarding the use of public in response to a request containing </ins> <del> , and response.cacheability for details of how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness.) </del> <ins> , and response.cacheability for how public affects responses that would normally not be stored, due to their status codes not being defined as heuristically cacheable; see heuristic.freshness. </ins> 5.2.2.7.
Code change:
I think this is the right thing to do; we added too much text here in 7234.
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
I'll trust you on the actual change :-)

Related discussion:
text: The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared <del> cache.  A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable. </del> <ins> cache. </ins> If the private response directive specifies one or more field names, this requirement is limited to the field values associated with the
Code change:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Related discussion:
text: trailing whitespace in values is significant will have to use a container syntax such as quoted-string (quoted.strings). <del> Because commas (",") are used as a generic delimiter between field values, they need to be treated with care if they are allowed in the field value.  Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production. </del> <ins> Because commas (",") are used as a generic delimiter between members of a list-based field value, they need to be treated with care if they are allowed as data within those members.  Typically, list members that might contain a comma are enclosed in a quoted-string. </ins> For example, a textual date and a URI (either of which might contain <del> a comma) could be safely carried in field values like these: </del> <ins> a comma) could be safely carried in list-based field values like these: </ins> Note that double-quote delimiters almost always are used with the quoted-string production; using a different syntax inside double-
Code change:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Related discussion:
text: 4.5. A #rule extension to the ABNF rules of RFC5234 is used to improve <del> readability in the definitions of some header field values. </del> <ins> readability in the definitions of some list-based field values. </ins> A construct "#" is defined, similar to "*", for defining comma- delimited lists of elements.  The full form is "<n>#<m>element"
Code change:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Related discussion:
text: identifying the protocol capabilities of senders along the request/ response chain. <del> Multiple Via field values represent each proxy or gateway that has forwarded the message.  Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients. </del> <ins> Each member of the Via field value represents a proxy or gateway that has forwarded the message.  Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients. </ins> A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards.  An HTTP-to-HTTP gateway
Code change:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Related discussion:
text: protocol.version.  For brevity, the protocol-name is omitted when the received protocol is HTTP. <del> The received-by portion of the field value is normally the host and optional port number of a recipient server or client that subsequently forwarded the 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 received on the default TCP port, if any, for the received-protocol. </del> <ins> The received-by portion is normally the host and optional port number of a recipient server or client that subsequently forwarded the 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 received on the default TCP port, if any, for the received-protocol. </ins> <del> A sender MAY generate comments in the Via header field to identify the software of each recipient, analogous to the </del> <ins> A sender MAY generate comments to identify the software of each recipient, analogous to the </ins> and <del> header fields.  However, all comments in the Via field are optional, and a recipient MAY remove them prior to forwarding the message. </del> <ins> header fields.  However, comments in Via are optional, and a recipient MAY remove them prior to forwarding the message. </ins> For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
Code change:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Related discussion:
text: the firewall by an appropriate pseudonym for that host. An intermediary MAY combine an ordered subsequence of Via header <del> field entries into a single such entry if the entries have identical </del> <ins> field list members into a single member if the entries have identical </ins> received-protocol values.  For example, could be collapsed to <del> A sender SHOULD NOT combine multiple entries unless they are all </del> <ins> A sender SHOULD NOT combine multiple list members unless they are all </ins> under the same organizational control and the hosts have already been <del> replaced by pseudonyms.  A sender MUST NOT combine entries that have </del> <ins> replaced by pseudonyms.  A sender MUST NOT combine members that have </ins> different received-protocol values. 5.6.2.
Code change:
Does not address Vary (see ), and some more discussion of some of the conditional request headers might be warranted.
Similar to , we need to use consistent language when talking about list values. Includes: [ ] Vary:

Related discussion:
text: the request to the origin server.  A proxy MUST NOT generate a Vary field with a "*" value. <del> A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </del> <ins> A Vary field value consisting of a list of field names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation.  The potential selecting header fields are not limited to those defined by this specification. </ins> For example, a response that contains
Code change:
That's
says: I think this should be:
Discussed in Basel. The current ABNF defines as a special value which only invokes the semantics when it's the entire field value; otherwise, it becomes a field name (since it's valid according to the field-name ABNF) and effectively gets ignored (since it's not going to be in normal requests). An alternative way of looking at it is to say that it's a special field name that, when it occurs anywhere in the Vary field value, it effectively turns off caching, no matter what the rest of the field value contains. Waiting for data to see what implementations do. Either way, this needs some examples in the spec, since it's so special.
See some results . It looks like all browser engines will turn off caching if `.
Duplicate of ? See also .
NAME shhh, we're trying to inflate our issue stats.

Related discussion:
text: A <del> header field-value of "*" always fails to match. </del> <ins> header field value containing a member "*" always fails to match. </ins> The stored response with matching selecting header fields is known as the selected response.
Code change:
We should explicitly tell them to reserve it.
I think the last comma is bad, but not enough to tweak it myself.

Related discussion:
text: by the recipient. When defining new connection options, specification authors ought to <del> survey existing field names and ensure that the new connection option does not share the same name as an already deployed field.  Defining a new connection option essentially reserves that potential field name for carrying additional information related to the connection option, since it would be unwise for senders to use that field name for anything else. </del> <ins> document it as reserved field name and register that definition in the Hypertext Transfer Protocol (HTTP) Field Name Registry (field.name.registry), to avoid collisions. </ins> The "
Code change:
We should explicitly tell them to reserve it.
I think the last comma is bad, but not enough to tweak it myself.

Related discussion:
text: 12.1. <del> Please update the "Hypertext Transfer Protocol (HTTP) Field Registry" registry at <https://www.iana.org/assignments/http-fields> with the </del> <ins> Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the </ins> field names listed in the two tables of header.field.syntax. 12.2.
Code change:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Related discussion:
text: A shared cache MUST NOT use a cached response to a request with an header field (header.authorization) to satisfy any subsequent request <del> unless a response directive that allows such responses to be stored is present. </del> <ins> unless the response contains a </ins> <del> In this specification, the following </del> <ins> field with a response directive (cache-response-directive) that allows it to be stored by a shared cache and the cache conforms to the requirements of that directive for that response. </ins> <del> response directives (cache-response-directive) have such an effect: must-revalidate, public, and s-maxage. </del> <ins> In this specification, the following response directives have such an effect: must-revalidate (cache-response-directive.must-revalidate), public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). </ins> 3.3.
Code change:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Related discussion:
text: not to be needed for single-entry lists). Although it has been back-ported to many implementations, some <del> HTTP/1.0 caches will not recognize or obey this directive.  Also, no- cache response directives with field names are often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented. </del> <ins> HTTP/1.0 caches will not recognize or obey this directive.  Also, the qualified form of the directive is often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented. </ins> 5.2.2.4.
Code change:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Related discussion:
text: 8.1. <del> Please update the "Hypertext Transfer Protocol (HTTP) Field Registry" registry at <https://www.iana.org/assignments/http-fields> with the </del> <ins> Please update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" at <https://www.iana.org/assignments/http-fields> with the </ins> field names listed in the two tables of header.field.definitions. 8.2.
Code change:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Related discussion:
text: explicit expiration time F <ins> Fields Age Cache-Control Expires Pragma Warning </ins> fresh freshness lifetime
Code change:
This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.

Related discussion:
text: VCHAR H <ins> Header Fields Age Cache-Control Expires Pragma Warning </ins> heuristic expiration time heuristically cacheable