jiebi/CodeConvo huggingface dataset:
Code change:
… section;
Hi Roy, Please consider this reference for the privacy considerations section: Bujlow, T., Carela-Español, V., Solé-Pareta, J., & Barlet-Ros, P. (2017). A survey on web tracking: Mechanisms, implications, and defenses. Proceedings of the IEEE, 105(8), 1476–1510. Regards, Rob
URL
NAME has done a lot of work in this area, so he might have another suggestion. The referenced paper does cover a good amount of techniques that target HTTP itself, so I'd say that it's worth citing unless a better option presents itself.

Related discussion:
text: environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP.  Fingerprinting is considered a privacy concern because it enables tracking of a user <del> agent's behavior over time without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </del> <ins> agent's behavior over time (Bujlow) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies).  Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints. </ins> There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable
Code change:
NAME see revision.
The language for and indicates that they override the rest of the caching model unconditionally; as discussed in , that is too broad. Also, is often used even though the message is still cacheable, because developers misunderstand its semantics.
The text in question for private: to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. lists one or more field names, then only the listed fields are limited to a single user: a shared cache [...] &MAY; store the remainder of the response message without those fields. I think there are two problems here: 1) "subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability). 2) The second paragraph omits any such condition. I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add to the list in section 3 (probably below .
For public, we have: response even if it would otherwise be prohibited, subject to the constraints of any other response directives present. In other words, public explicitly marks the response as cacheable. Similar to above, I think it should be "subject to the constraints defined in [ref to section 3]. A note like this would also help:
LGTM.

Related discussion:
text: The "public" response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the <del> constraints of any other response directives present.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). </del> <ins> constraints defined in response.cacheability.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). Note that it is not necessary to add the public directive to a response that is already cacheable according to response.cacheability. </ins> <del> If no explicit freshness information is provided, the response is is heuristically cacheable (heuristic.freshness). </del> <ins> If no explicit freshness information is provided on a response with the public directive, it is heuristically cacheable (heuristic.freshness). </ins> 5.2.2.7.
Code change:
NAME see revision.
The language for and indicates that they override the rest of the caching model unconditionally; as discussed in , that is too broad. Also, is often used even though the message is still cacheable, because developers misunderstand its semantics.
The text in question for private: to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. lists one or more field names, then only the listed fields are limited to a single user: a shared cache [...] &MAY; store the remainder of the response message without those fields. I think there are two problems here: 1) "subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability). 2) The second paragraph omits any such condition. I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add to the list in section 3 (probably below .
For public, we have: response even if it would otherwise be prohibited, subject to the constraints of any other response directives present. In other words, public explicitly marks the response as cacheable. Similar to above, I think it should be "subject to the constraints defined in [ref to section 3]. A note like this would also help:
LGTM.

Related discussion:
text: The unqualified "private" response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user).  It also indicates that a private cache MAY store the <del> response, subject to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. </del> <ins> response, subject the constraints defined in response.cacheability, even if the response would not otherwise be heuristically cacheable by a private cache. </ins> If a qualified private response directive is present, with an argument that lists one or more field names, then only the listed fields are limited to a single user: a shared cache MUST NOT store the listed fields if they are present in the original response, but <del> MAY store the remainder of the response message without those fields. </del> <ins> MAY store the remainder of the response message without those fields, subject the constraints defined in response.cacheability. </ins> The field names given are not limited to the set of header fields defined by this specification.  Field names are case-insensitive.
Code change:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Related discussion:
text: request: i.e., a response to a GET request, which contains a representation of the <del> resource identified by the request target (GET).  However, it is also possible to store redirects, negative results (e.g., </del> <ins> target resource (GET).  However, it is also possible to store redirects, negative results (e.g., </ins> ), incomplete results (e.g.,
Code change:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Related discussion:
text: 3.1. <del> A response message is considered complete when all of the octets indicated by its framing are available.  Note that, when no explicit framing is provided, a response message that is ended by the connection's close is considered complete even though it might be indistinguishable from an incomplete response (see Messaging).  A cache SHOULD consider a close-terminated response incomplete if the connection termination is detected to be an error.  A server that wishes to avoid premature termination resulting in an incorrect cached response SHOULD send the response with explicit framing. </del> If the request method is GET, the response status code is , and the entire response header section has been received, a cache <del> MAY store an incomplete response message body if the stored response is recorded as incomplete.  Likewise, a </del> <ins> MAY store a response body that is not complete (operation) if the stored response is recorded as being incomplete.  Likewise, a </ins> response MAY be stored as if it were an incomplete
Code change:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Related discussion:
text: When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request <del> using a stored response by copying the method, request-target, and </del> <ins> using a stored response by copying the method, target URI, and </ins> request header fields identified by the Vary header field caching.negotiated.responses.
Code change:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Related discussion:
text: stored response) or if transmission of the representation body is not desired even if it has changed. <del> When a cache makes an inbound HEAD request for a given request target and receives a </del> <ins> When a cache makes an inbound HEAD request for a given target URI and receives a </ins> response, the cache SHOULD update or invalidate each of its stored GET responses that could have been selected for that request (see
Code change:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Related discussion:
text: Because unsafe request methods (safe.methods) such as PUT, POST or DELETE have the potential for changing state on the origin server, <del> intervening caches can use them to keep their contents up to date. </del> <ins> intervening caches are required to invalidate stored responses to keep their contents up to date. means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated globally; a state-changing request would only invalidate responses in the caches that it travels through. </ins> <del> A cache MUST invalidate the effective Request URI (effective.request.uri) as well as the URI(s) in the </del> <ins> A cache MUST invalidate the target URI (target.resource) as well as the URI(s) in the </ins> and
Code change:
NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.

Related discussion:
text: or response header field if the host part of that URI differs from the <del> host part in the effective request URI (effective.request.uri).  This helps prevent denial-of-service attacks. </del> <ins> host part in the target URI (target.resource).  This helps prevent denial-of-service attacks. </ins> <del> A cache MUST invalidate the effective request URI (effective.request.uri) when it receives a non-error response to a request with a method whose safety is unknown. </del> <ins> A cache MUST invalidate the target URI (target.resource) when it receives a non-error response to a request with a method whose safety is unknown. </ins> Here, a "non-error response" is one with a or <del> status code.  "Invalidate" means that the cache will either remove all stored responses related to the effective request URI or will mark these as "invalid" and in need of a mandatory validation before they can be sent in response to a subsequent request. Note that this does not guarantee that all appropriate responses are invalidated.  For example, a state-changing request might invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it has not. </del> <ins> status code. </ins> 5.
Code change:
header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice. This should just be "HTTP", no?

Related discussion:
text: A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order: <del> Any extension to HTTP/1.1 that defines additional conditional request </del> <ins> Any extension to HTTP that defines additional conditional request </ins> header fields ought to define its own expectations regarding the order for evaluating such fields in relation to those defined in this document and other conditionals that might be found in practice.
Code change:
The current section on CONNECT (7.3.6) in the semantics document refers to the proxy forwarding packets: Since the proxy terminates TCP, there is no forwarding of IP packets, but rather the contents of the TCP streams.
Well spotted! I'd even suggest "to blindly forward bytes in both directions ...". Too often I see people who imagine that packet delimitation is respected on both sides of a proxy and I have to tell them that it's just a uninterrupted stream of bytes that each layer decides to delimit wherever it wants.
I'd say that 7231 is self-consistent with the use of packet in 7230. If a change is needed, we should change wording consistently. Or, was this issue raised on the WIP core doc?
NAME this issue is being raised on the WIP core doc. The same text does also exist in 7231, but I consider them to both be in error. While we're updating the text for the core doc, let's fix the text to be clearer.
Thanks for the clarification NAME that sounds good to me.
Fwiw, the HiNT draft uses the terminology: blind forwarding of IP payloads, UDP datagram payloads and TCP/IP packet payload.
HTTP/3 says:
NAME that text looks good. Something along those lines, but that also works for HTTP/1.1, would be right for this core doc text.
Maybe just replace "packets" with "data"?
So as mentioned above in , while having a look at the latest draft I was struck again by this "packets" there, and even forgot about this old issue. Pinging again. I suggest that we change "forwarding of packets" with "forwarding of the byte stream" so that we can close these issues.

Related discussion:
text: The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding <del> of packets, in both directions, until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, RFC8446). </del> <ins> of data, in both directions, until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, RFC8446). </ins> CONNECT is intended only for use in requests to a proxy.  An origin server that receives a CONNECT request for itself MAY respond with a
Code change:
URL This sentence describes cases where the selected representation exists and has an entity-tag. Shall we also specify that "if the selected representation does not exist or does not have an entity-tag, then the condition is false"?

Related discussion:
text: request. An origin server that receives an If-Match header field MUST evaluate <del> the condition prior to performing the method (evaluation).  If the field value is "*", the condition is false if the origin server does not have a current representation for the target resource.  If the field value is a list of entity-tags, the condition is false if none of the listed tags match the entity-tag of the selected representation. </del> <ins> the condition prior to performing the method (evaluation). To evaluate a received If-Match header field: </ins> An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server
Code change:
URL This sentence describes cases where the selected representation exists and has an entity-tag. Shall we also specify that "if the selected representation does not exist or does not have an entity-tag, then the condition is false"?

Related discussion:
text: An origin server that receives an If-None-Match header field MUST evaluate the condition prior to performing the method (evaluation). <del> If the field value is "*", the condition is false if the origin server has a current representation for the target resource.  If the field value is a list of entity-tags, the condition is false if one of the listed tags match the entity-tag of the selected representation. </del> <ins> To evaluate a received If-None-Match header field: </ins> An origin server MUST NOT perform the requested method if the condition evaluates to false; instead, the origin server MUST respond
Code change:
P-A is as: This seems really odd -- P-A is not generally used in a way that's specific to a single target URI.
I think it's scoped to the request; i.e., if the client retries the same request with appropriate credentials, it's likely to succeed; we can't say much more than that.
FTR, the text we have is inherited from .

Related discussion:
text: status code is similar to , but it indicates that the client needs to authenticate itself in <del> order to use a proxy.  The proxy MUST send a </del> <ins> order to use a proxy for this request.  The proxy MUST send a </ins> header field (field.proxy-authenticate) containing a challenge <del> applicable to that proxy for the target resource.  The client MAY repeat the request with a new or replaced </del> <ins> applicable to that proxy for the request.  The client MAY repeat the request with a new or replaced </ins> header field (field.proxy-authorization).
Code change:
P-A is as: This seems really odd -- P-A is not generally used in a way that's specific to a single target URI.
I think it's scoped to the request; i.e., if the client retries the same request with appropriate credentials, it's likely to succeed; we can't say much more than that.
FTR, the text we have is inherited from .

Related discussion:
text: The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters <del> applicable to the proxy for this target URI (target.resource).  A proxy MUST send at least one Proxy-Authenticate header field in each </del> <ins> applicable to the proxy for this request.  A proxy MUST send at least one Proxy-Authenticate header field in each </ins> response that it generates.
Code change:
These "(or laters)" don't seem to be accurate.
Suggest "(or later minor revisions of HTTP/1)"

Related discussion:
text: that implementations advertising only HTTP/1.0 support will not understand how to process a transfer-encoded payload.  A client MUST NOT send a request containing Transfer-Encoding unless it knows the <del> server will handle HTTP/1.1 (or later) requests; such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). </del> <ins> server will handle HTTP/1.1 requests (or later minor revisions); such knowledge might be in the form of specific user configuration or by remembering the version of a prior received response.  A server MUST NOT send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later minor revisions). </ins> A server that receives a request message with a transfer coding it does not understand SHOULD respond with
Code change:
changes to -messaging pulled from URL
I'll go ahead with this one as we already reached consensus in the original PR.

Related discussion:
text: the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR. <ins> A sender MUST NOT generate a bare CR (a CR character not immediately followed by LF) within any protocol elements other than the payload body.  A recipient of such a bare CR MUST consider that element to be invalid or replace each bare CR with SP before processing the element or forwarding the message. </ins> Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a workaround for some early server applications that failed to read message body content that was not
Code change:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Related discussion:
text: account when creating a new HTTP field. The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is <del> located at "https://www.iana.org/assignments/http-fields/". </del> <ins> located at <https://www.iana.org/assignments/http-fields/>. </ins> Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@ietf.org" mailing list. Field names are registered on the advice of a Designated Expert (appointed by the IESG or their delegate).  Fields with the status <del> 'permanent' are Specification Required (using terminology from RFC8126). </del> <ins> 'permanent' are Specification Required (RFC8126). </ins> Registration requests consist of at least the following information: <ins> And, optionally: </ins> The Expert(s) can define additional fields to be collected in the registry, in consultation with the community.
Code change:
this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.

Related discussion:
text: limit their values to US-ASCII octets.  A recipient SHOULD treat other octets in field content (obs-text) as opaque data. <ins> Field values containing control ( ) characters such as CR or LF are invalid; recipients MUST either reject a field value containing control characters, or convert them to SP before processing or forwarding the message. </ins> Leading and trailing whitespace in raw field values is removed upon field parsing (field.parsing).  Field definitions where leading or trailing whitespace in values is significant will have to use a