jiebi/CodeConvo huggingface dataset:
Code change:
This just fixes a typo, but this text has more problems. I'm having trouble connecting this final sentence to the text that precedes it. I think that the point is that including a body on GET is unwise because it might cause explosions. A point about side effects needs far more exposition, especially since GET is defined to be free from overt side effects (safe, idempotent, and all that business). If this were just another statement and the "As a result" is dropped, that's different.
Barg, I think that's a copy/paste error, will fix. thx.

Related discussion:
text: syntactically, this is done only to allow parsers to be generic; as per RFC7231, Section 4.3.1, a body on a GET has no meaning, and will be either ignored or rejected by generic HTTP software.  As a result, <del> applications that use HTTP SHOULD NOT define GET to have any sde </del> <ins> applications that use HTTP SHOULD NOT define GET to have any side </ins> effects upon their resources. 4.6.
Code change:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Related discussion:
text: cache or by forwarding the request towards the origin - by following the algorithm defined in cache. <del> Its companion the Variant-Key response header field (variant-key) indicates which representation was selected, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </del> <ins> Its companion Variant-Key response header field (variant-key) indicates the applicable key(s) that the response is associated with, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </ins> Proactive content negotiation mechanisms that wish to be used with Variants need to define how to do so explicitly; see define.  As a
Code change:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Related discussion:
text: 3. The Variant-Key HTTP response header field is used to indicate the <del> value(s) from the Variants header field that identify the </del> <ins> values from the Variants header field that identify the </ins> representation it occurs within. <del> Each value indicates the selected available-value, in the same order as the variants listed in the Variants header field. </del> <ins> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </ins> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to
Code change:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Related discussion:
text: This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> Note that Variant-Key is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself.  In the example above, it might be that a gzip'd version of the French content is not available, in which case the response will include: </del> <ins> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </ins> <del> even though Content-Encoding does not contain "gzip". </del> <ins> indicates that this response can be used for requests whose Content- Encoding algorithm selects "gzip" or "identity", as long as the Content-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </ins> 3.1. <del> This algorithm generates a normalised string for Variant-Key, suitable for comparison with values generated by cache. </del> <ins> This algorithm generates a list of normalised strings from Variant- Key, suitable for comparison with values generated by cache. </ins> Given stored-headers, a set of headers from a stored response, a <del> normalised variant-key for that message can be generated by: </del> <ins> normalised list of variant-keys for that message can be generated by: Let variant-keys be an empty list. </ins> Let variant-key-header be a string, the result of selecting all field-values of stored-headers whose field-name is "Variant-Key" and joining them with a comma (","). <del> Remove all whitespace from variant-key-header. </del> <ins> Let value-list be the result of splitting variant-key-header on commas (","). For each value in value-list: Remove all whitespace from value. Let items be the result of splitting value on ";". append items to variant-keys. </ins> <del> Return variant-key-header. </del> <ins> Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </ins> 4.
Code change:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Related discussion:
text: indicating available-values that are acceptable to the client, in order of preference, greatest to least. <del> Return result of running Find Available Keys (find) on sorted- </del> <ins> Return result of running Compute Possible Keys (find) on sorted- </ins> variants, an empty string and an empty list. This returns a list of strings suitable for comparing to normalised
Code change:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Related discussion:
text: 4.1. <del> Given sorted-variants, a list of lists, and key-stub, a string </del> <ins> Given key-facets, a list of lists, and key-stub, a string </ins> representing a partial key, and possible-keys, a list: <del> Let sorted-values be the first member of sorted-variants. </del> <ins> Let values be the first member of key-facets. </ins> <del> For each sorted-value in sorted-values: </del> <ins> For each value in values: </ins> If key-stub is an empty string, let this-key be a copy of <del> sorted-value. </del> <ins> value. </ins> Otherwise:
Code change:
For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)

Related discussion:
text: Append a comma (",") to this-key. <del> Append sorted-value to this-key. </del> <ins> Append value to this-key. </ins> <del> Let remaining-variants be a copy of all of the members of sorted-variants except the first. </del> <ins> Let remaining-facets be a copy of all of the members of key- facets except the first. </ins> <del> If remaining-variants is empty, append this-key to possible- keys. </del> <ins> If remaining-facets is empty, append this-key to possible-keys. </ins> <del> Otherwise, run Find Available Keys on remaining-variants, this- </del> <ins> Otherwise, run Find Available Keys on remaining-facets, this- </ins> key and possible-keys. Return possible-keys.
Code change:
There is currently a discrepancy in the spec regarding invalid values in the SameSite cookie attribute. For example, this cookie: Set-Cookie: foo=bar; SameSite=bogus is expected to be dropped entirely according to the "Server Requirements" under Section 4.1.2.7: If the "SameSite" attribute's value is neither of these [ "Lax", "Strict" ], the cookie will be ignored. whereas under Section 5.3.7 of "User Agent Requirements", the cookie is to be kept but the attribute is ignored: If cookie-av's attribute-value is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av". Additionally, the end of Section 4.1.2 also matches the behavior described in Section 5.3.7: User agents ignore unrecognized cookie attributes (but not the entire cookie). From a forward-compatibility point of view, the behavior described in section 5.3.7 is the ideal one since it allows for future expansion of this feature such as: Set-Cookie: foo=bar; SameSite=medium
NAME
Done. Let me know if I missed anything else.
URL Section 3.1 of the spec states that "SameSite" alone (without an attribute value) is a valid token: URL Section 4.1 URL states If "cookie-av"'s "attribute-value" is not a case-insensitive match for "Strict" or "Lax", ignore the "cookie-av".
Ah. URL draft is outdated vs. URL The latter no longer allows a bare "SameSite" token, and it calls for the cookie to be dropped in the event that the samesite-value isn't either "strict" or "lax". However, I think this text isn't quite right: If 's is not a case-insensitive match for "Strict" or "Lax", ignore the . The in this case is 'SameSite=whatever' and we want to ignore the whole cookie, not just the invalid attribute?
is my proposal to fix this. We ran into this issue in the Firefox implementation: URL
Thanks!

Related discussion:
text: be sent along with "same-site" requests.  If the value is "Lax", the cookie will be sent with same-site requests, and with "cross-site" top-level navigations, as described in strict-lax.  If the "SameSite" <del> attribute's value is neither of these, the cookie will be ignored. </del> <ins> attribute's value is neither of these, the attribute will be ignored. </ins> 4.1.3.
Code change:
Also considering if "Security Considerations" can be "Compatibility Considerations".
I haven't renamed "Security Considerations" in this version. And I have no issue with calling this "Compatibility Considerations". But I have some recollection that this is a required section...
Yeah don't do that or various people will start to scream at you :)
Call me a perfectionist, but on reread, I realized there was a cleaner/shorter way to clarify. Let me know if you have any objection...
Thanks Martin!

Related discussion:
text: where the last-byte-pos in the Request is much larger than the last- byte-pos returned in response to an open-ended byte-range HEAD <del> request, as described above. </del> <ins> request, as described above, and much larger than the expected maximum size of the representation.  See Security for range value considerations. </ins> In response, a server may indicate that it is supplying a continuously aggregating ("live") response by supplying the client
Code change:
According to RFC 7231, Section 8.3.1. I didn't include anything here about Vary because I wanted to discuss that first and these seemed uncontroversial. It seems OK to say that Vary is permitted here because we expressly talk about varied reactions based on the presence of Early-Data. If that's right, I will amend this with a second commit. (I'm jetlagged, so being a little cautious.)
Your proposal looks very clear to me, despite your jetlag :-) I agree with you that Vary should be OK. I don't even think we need to say anything about it then.

Related discussion:
text: (see be-consistent for details). An intermediary MUST NOT remove this header field if it is present in <del> a request. </del> <ins> a request.  "Early-Data" MUST NOT appear in a "Connection" header field. </ins> The "Early-Data" header field is not intended for use by user agents (that is, the original initiator of a request).  Sending a request in
Code change:
According to RFC 7231, Section 8.3.1. I didn't include anything here about Vary because I wanted to discuss that first and these seemed uncontroversial. It seems OK to say that Vary is permitted here because we expressly talk about varied reactions based on the presence of Early-Data. If that's right, I will amend this with a second commit. (I'm jetlagged, so being a little cautious.)
Your proposal looks very clear to me, despite your jetlag :-) I agree with you that Vary should be OK. I don't even think we need to say anything about it then.

Related discussion:
text: be safely processed MUST be rejected using the 425 (Too Early) status code. <ins> The "Early-Data" header field carries a single bit of information and clients MUST include at most one instance.  Multiple instances MUST be treated as equivalent to a single instance by a server. A "Early-Data" header field MUST NOT be included in responses or request trailers. </ins> 5.2. A 425 (Too Early) status code indicates that the server is unwilling
Code change:
Our basic list of mitigations missed a fairly obvious one. Mentioning it should help with the class of confusion Magnus N. had with the draft. I decided not to include a note about the server being unable to examine early data before making this decision. That's just something people will need to discover for themselves. Generally, you have to decide whether you want 0-RTT without seeing any of it. Partly this is because it avoids a potential deadlock, but mostly it's because the TLS stack will not even decrypt 0-RTT if it is rejected.
Looks good to me, and indeed clearer. Thanks.
+1

Related discussion:
text: eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> The server can choose whether it will process early data before the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </del> <ins> The server can reject early data.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </ins> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can
Code change:
This was a little obtuse in the previous iteration, likely as a result of trying to be parsimonious. Expand it a little and clarify the attack.
It's indeed better like this in my opinion.

Related discussion:
text: data MUST be sent again, unless the client decides to abandon those requests. <del> This automatic retry exposes the request to a potential replay attack.  An attacker sends early data to one server instance that accepts and processes the early data, but allows that connection to proceed no further.  The attacker then forwards the same messages from the client to another server instance that will reject early data.  The client then retries the request, resulting in the request being processed twice.  Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </del> <ins> Automatic retry creates the potential for a replay attack.  An attacker intercepts a connection that uses early data and copies the early data to another server instance.  The second server instance accepts and processes the early data.  The attacker then allows the original connection to complete.  Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete.  If the client then retries requests that were sent in early data, the request will be processed twice. Replays are also possible if there are multiple server instances that will accept early data, or if the same server accepts early data multiple times (though this would be in violation of requirements in Section 8 of TLS13). </ins> Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see status.
Code change:
URL too wide artwork by changing the second example to use multiple field instances (which, in itself, is good to have in the examples anyway)
Thanks!

Related discussion:
text: 2.1.4. <del> The following examples demonstrate valid Expect-CT response header fields: </del> <ins> The following three examples demonstrate valid Expect-CT response header fields (where the second splits the directives into two field instances): </ins> 2.2.
Code change:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Related discussion:
text: <del> The Tunnel-Protocol HTTP Header Field </del> <ins> The ALPN HTTP Header Field </ins> draft-ietf-httpbis-tunnel-protocol-latest Abstract This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the <del> Tunnel-Protocol header field. </del> <ins> ALPN header field. </ins> Editorial Note (To be removed by RFC Editor)
Code change:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Related discussion:
text: Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies. <del> The HTTP Tunnel-Protocol header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </del> <ins> The HTTP ALPN header field identifies the protocol that will be spoken within the tunnel, using the Application Layer Protocol Negotiation identifier (ALPN, RFC7301). </ins> <del> When the CONNECT method is used to establish a tunnel, the Tunnel- Protocol header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </del> <ins> When the CONNECT method is used to establish a tunnel, the ALPN header field can be used to identify the protocol that the client intends to use with that tunnel.  For a tunnel that is then secured using RFC5246, the header field carries the same application protocol label as will be carried within the TLS handshake.  If there are multiple possible application protocols, all of those application </ins> protocols are indicated. <del> The Tunnel-Protocol header field carries an indication of client intent only.  In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other protocols could negotiate protocols differently. </del> <ins> The ALPN header field carries an indication of client intent only. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client.  Other protocols could negotiate protocols differently. </ins> Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header
Code change:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Related discussion:
text: 2. <del> Clients include the Tunnel-Protocol header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </del> <ins> Clients include the ALPN header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel. </ins> 2.1.
Code change:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Related discussion:
text: 2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del> <ins> The ABNF (Augmented Backus-Naur Form) syntax for the ALPN header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) MUST
Code change:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Related discussion:
text: HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- <del> headers>.  This document defines and registers the Tunnel-Protocol header field, according to RFC3864 as follows: </del> <ins> headers>.  This document defines and registers the ALPN header field, according to RFC3864 as follows: </ins> <del> Tunnel-Protocol </del> <ins> ALPN </ins> http
Code change:
Last call discussion identified this as a solution to the confusion that exists around the intent of the header field.
Apparently, this is confusing. Picking a new name might help.

Related discussion:
text: Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </del> <ins> The ALPN header field described in this document is an OPTIONAL header field.  Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is </ins> indistinguishable from the case where either client or proxy does not <del> support the Tunnel-Protocol header field. The value of the Tunnel-Protocol header field could be falsified by a client.  If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the Tunnel-Protocol header field as a policy input in all cases. </del> <ins> support the ALPN header field. The value of the ALPN header field could be falsified by a client. If the data being sent through the tunnel is encrypted (for example, with RFC5246), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis TRAFFIC.  A proxy therefore cannot rely on the value of the ALPN header field as a policy input in all cases. </ins>
Code change:
They were both special, but for some reason the first reference wasn't getting brackets in the text output. Putting whitespace between them doesn't affect that, but putting other characters does.
LGTM. (And yes, I tried whitespace as well :-)

Related discussion:
text: HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from.  The traditional form of server authentication in HTTP has been <del> in the form of a single X.509 certificate provided during the TLS I- D.ietf-tls-tls13 handshake. </del> <ins> in the form of a single X.509 certificate provided during the TLS (RFC5246, I-D.ietf-tls-tls13) handshake. </ins> Many existing HTTP RFC7230 servers also have authentication requirements for the resources they serve.  Of the bountiful