jiebi/CodeConvo huggingface dataset:
Code change:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Related discussion:
text: as shown here. Conformance criteria and considerations regarding error handling are <del> defined in Semantics-conformance. </del> <ins> defined in Semantics. </ins> 1.2.
Code change:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Related discussion:
text: robustness (see request.smuggling). HTTP does not place a predefined limit on the length of a request- <del> line, as described in Semantics-conformance.  A server that receives a method longer than any that it implements SHOULD respond with a </del> <ins> line, as described in Semantics.  A server that receives a method longer than any that it implements SHOULD respond with a </ins> status code.  A server that receives a request-target longer than any URI it wishes to parse MUST respond with a
Code change:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Related discussion:
text: The <del> of request-target is only used for CONNECT requests (CONNECT). </del> <ins> of request-target is only used for CONNECT requests (CONNECT).  It consists of only the and number of the tunnel destination, separated by a colon (":"). </ins> When making a CONNECT request to establish a tunnel through one or <del> more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target.  For example, </del> <ins> more proxies, a client MUST send only the host and port of the tunnel destination as the request-target.  The client obtains the host and port from the target URI's component, except that the scheme's default port is sent if the target URI elides the port.  For example, a CONNECT request to "http://www.example.com" looks like </ins> 3.2.4.
Code change:
... components, depending on the form of request-target, and when authority might be empty. This is an alternative to
In determining the request target, the following text is included after failing to find an authority in configuration, the authority form target, or the Host header: This is a security risk because it means that servers might not agree with clients about the identity of the resource that the request is directed to. This is especially bad as a TLS certificate is good for every port and often good for multiple names, which can mean a fairly large scope over which an attacker can exploit this confusion. The origin form description doesn't use 2119 language, it says "A Host header field is also sent", citing . And that section is a bit weaselly in that regard, using a "URL". If this were a "MUST ... unless" in -semantics, this problem would not exist (at least in theory). Just to confuse things, the absolute-form says , which might be read to imply that Host truly is mandatory: The asterisk-form is the only other option that naturally lacks an authority, and that says nothing, so that might be fixed up similarly.
Keep in mind that the first text is what to do when receiving a message without Host or absolute-form, whereas the other texts are requirements on generation. Yes, it is a security risk to not send Host, and I assume it would be one to provide service for an https resource without verifying that the client's request indicates one of the server's host (somehow). So, PR welcome, but the final text still needs to accept non-TLS HTTP/1.0 requests without a Host (for ass-backwards reasons).
BTW, the reason it says SHOULD here instead of MUST is because this requirement about the ordering of fields in the header section, not about whether or not Host needs to be sent.
OK, that's good. It's not a genuine problem, we just need to be clearer about generation requirements (and we might be able to carefully condition the inclusion of a default).
better again

Related discussion:
text: When a message does not have a <del> header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for potential content.  For messages that do include content, the Content-Length field value provides the framing information necessary for determining where the data (and message) ends.  For messages that do not include content, the Content-Length indicates the size of the </del> <ins> header field, a Content-Length header field (field.content-length) can provide the anticipated size, as a decimal number of octets, for potential content.  For messages that do include content, the Content-Length field value provides the framing information necessary for determining where the data (and message) ends.  For messages that do not include content, the Content-Length indicates the size of the </ins> selected representation (field.content-length). A sender MUST NOT send a Content-Length header field in any message
Code change:
In 3.2.3. authority-form it says Whereas it needs to specifically require host:port, as in the definition of :
does this merit a change log entry?

Related discussion:
text: The <del> of request-target is only used for CONNECT requests (CONNECT). </del> <ins> of request-target is only used for CONNECT requests (CONNECT).  It consists of only the and number of the tunnel destination, separated by a colon (":"). </ins> When making a CONNECT request to establish a tunnel through one or <del> more proxies, a client MUST send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target.  For example, </del> <ins> more proxies, a client MUST send only the host and port of the tunnel destination as the request-target.  The client obtains the host and port from the target URI's component, except that the scheme's default port is sent if the target URI elides the port.  For example, a CONNECT request to "http://www.example.com" looks like </ins> 3.2.4.
Code change:
The spec currently says this about data sent along with a CONNECT request: Is there a demarcation between data "within" a request and data to be sent on the tunnel if it opens successfully? HTTP/2 and HTTP/3 are fairly specific that all DATA frames are data for the tunnel. Do we need to say anything about the client prospectively sending data before the proxy responds?
We should decide what we want to allow. If HTTP/3 is going to send CONNECT data within HTTP/3 frame payloads after (or before) the recipient accepts the CONNECT, then we should specify it differently than how we specified CONNECT in 1.1. I am fine with that.
Hm. Does this imply we special-case 1.1, and require the HTTP/2/3 behaviour for new versions?
I think it is already a special case for 1.1, so that's not a problem.
OK, let me rephrase this then :-). Are we trying to make it consistent for all "new" versions?
Given that CONNECT is specified on a version-by-version basis anyway, I think I'd rephrase it with something like this: CONNECT is one of those weird edges of the protocol where each version will have to respecify its behavior; we don't necessarily need to prescribe what it will be, just make allowances for versions to differ.

Related discussion:
text: Transfer-Encoding header fields received in a successful response to CONNECT. <del> Content within a CONNECT request message has no defined semantics; sending content in a CONNECT request might cause some existing implementations to reject the request. </del> <ins> A CONNECT request message does not have content.  The interpretation of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.
Code change:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Related discussion:
text: HTTP/1.1 defaults to the use of , allowing multiple requests and responses to be carried over a <del> single connection.  The " " connection option is used to signal that a connection will not persist after the current request/response.  HTTP implementations SHOULD support persistent connections. </del> <ins> single connection.  HTTP implementations SHOULD support persistent connections. </ins> A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version and
Code change:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Related discussion:
text: A client that does not support <del> MUST send the "close" connection option in every request message. </del> <ins> MUST send the connection option in every request message. </ins> A server that does not support <del> MUST send the "close" connection option in every response message that does not have a </del> <ins> MUST send the connection option in every response message that does not have a </ins> status code. A client MAY send additional requests on a persistent connection <del> until it sends or receives a " </del> <ins> until it sends or receives a </ins> <del> " connection option or receives an HTTP/1.0 response without a "keep- </del> <ins> connection option or receives an HTTP/1.0 response without a "keep- </ins> alive" connection option. In order to remain persistent, all messages on a connection need to
Code change:
The close connection item used to be defined in Connection as whereas now its effect is described in Messaging without definition. I think it should be defined somewhere.
gets pretty close to that text: ... with text below that elaborates. What do you want to see here?
looks good except as noted by NAME the bare close strings look weird.LGTM, except for 'the close' being a bit weird (but I don't feel that strongly about it; suggestions for replacement inline).

Related discussion:
text: problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). <del> Note that the field name "Close" is reserved, since using that name as an HTTP header field might conflict with the "close" connection defined above. </del> See compatibility.with.http.1.0.persistent.connections for more information on backwards compatibility with HTTP/1.0 clients.
Code change:
without changing section numbering
implies that a precondition failure is a good safe mode. However, a precondition that isn't recognized by a server will not share this property. A server that does not recognize a header as a precondition will ignore it and likely proceed with handling the request even if the precondition expressed should have failed. Indeed, the same is true if a server ignores preconditions, though the specification effectively . is the only text I could find on defining new preconditions. (One thing I really want to avoid is server's applying special heuristics to headers that start with , because that is one of many poor outcomes if this is left.)
There is also the example in the section above that I suppose we could make a new section on precondition extensions, but they aren't a separate category (like If*). For example, my precondition proposal for 1.1 was an all-inclusive Unless that enclosed a logic bag (structured field value). Note that they have always depended on compliance-when-implemented, since I added the first (If-Modified-Since) in early 1994.
Does this need to be in this specification?
I think we're almost in the extension territory (I like the idea of a header field that lists the applicable precondition fields). As far as this specification goes, simply noting that new preconditions won't share properties of the core preconditions, in particular the expectation that it is understood by servers.
One grammatical nit.

Related discussion:
text: directive (defined by RFC8246) instructs caches to forgo revalidation of fresh responses even when requested by the client. <del> Conditional request header fields that are defined by extensions to HTTP might place conditions on all recipients, on the state of the target resource in general, or on a group of resources.  For instance, the "If" header field in WebDAV can make a request conditional on various aspects of multiple resources, such as locks, if the recipient understands and implements that field (RFC4918). </del> Although conditional request header fields are defined as being usable with the HEAD method (to keep HEAD's semantics consistent with those of GET), there is no point in sending a conditional HEAD
Code change:
to clients that attempt to guess (editorial)
I have no idea what this is trying to say and it is 1.1-specific. I suggest we delete it.
It was added as part of URL, adressing .
How about
May end up encouraging this kind of implementation, by providing an example here ... ? Maybe just leave this as "Some clients take a riskier approach and attempt to guess when an automatic retry is possible because the original request may not have been received by the server." ....
I don't see any problem with the original text, but NAME your replacement is fine too (although the second sentence is a fragment).
How about

Related discussion:
text: changes that were partially applied, and then automatically retrying the requests that failed. <del> Some clients use weaker signals to initiate automatic retries.  For example, when a POST request is sent, but the underlying transport connection is closed before any part of the response is received. Although this is commonly implemented, it is not recommended. </del> <ins> Some clients take a riskier approach and attempt to guess when an automatic retry is possible.  For example, a client might automatically retry a POST request if the underlying transport connection closed before any part of a response is received, particularly if an idle persistent connection was used. </ins> A proxy MUST NOT automatically retry non-idempotent requests.  A client SHOULD NOT automatically retry a failed automatic retry.
Code change:
I am seeing a lot of warnings about lines being too long (longer than 72 characters), but they are unrelated to these changes.
This changed "previous authors, editors, and Working Group Chairs" to "current and previous authors"; that's misleading, as it actually does not contain any current authors. Originally posted by NAME in URL
This is what I had in mind in terms of bringing back the original acks.

Related discussion:
text: protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. <del> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </del> <ins> This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </ins> Editorial Note
Code change:
Nits on semantics flags this: -- The draft header indicates that this document updates RFC3864, but the abstract doesn't seem to mention this, which it should.
Can you point to a document that states this?

Related discussion:
text: protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. <del> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </del> <ins> This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </ins> Editorial Note
Code change:
Should we leave these open until after IESG last call, or just apply them now?
Good Q. NAME ?
I think it'd be preferable to not cut another version until we get through the IETF last call. However, if we want to merge this and just keep a note of the changes, I don't see any issue.
I think it would be preferable, just to avoid people raising the same issues again, and also to get the Index into the last call version.
HEAD says whereas the new text for GET is and similarly for DELETE. We should update HEAD as well to be
Digging in the change logs: the text for GET comes from URL (with subsequent tuning).

Related discussion:
text: and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency. <del> A content within a HEAD request message has no defined semantics; sending content in a HEAD request might cause some existing implementations to reject the request. </del> <ins> A client SHOULD NOT generate content in a HEAD request.  Content received in a HEAD request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling). </ins> The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the
Code change:
Used in 5.6.1, defined in 5.6.3. Minimally make the forward reference explicit.
And 5.3.

Related discussion:
text: that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma <del> and </del> <ins> (",") and optional whitespace ( </ins> <del> (optional whitespace).  For consistency, use comma SP. </del> <ins> , defined in whitespace).  For consistency, use comma SP. </ins> The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a