jiebi/CodeConvo huggingface dataset:
Code change:
Recently I noticed that the host header field is being discussed in . I believe that we should move the definition of the host header to the HTTP/1.1 messaging draft, and discuss about "authority" as a concept in the semantics draft, as the "host" header is specific to HTTP/1.1 (except for handling of broken HTTP/2 clients)?
Hi Kazuho, We discussed this on the editors' call. Host's semantics aren't specific to HTTP/1.1, even if its requirements are different in other protocol versions. That's why we moved it to Semantics; it's not version-specific (and really very few headers should be). Closing; if you feel it needs more discussion please request re-opening and we'll do so.
Thank you for the consideration. While I do understand the argument that the semantics of the header field is not version specific, the use is. I've opened a PR that tries to clarify that.
Thank you for the changes!

Related discussion:
text: implementing such verification can be difficult (see Georgiev). Authority for a given origin server can be delegated through protocol <del> extensions; for example, RFC7838.  Likewise, the set of servers that a connection is considered authoritative for can be changed with a </del> <ins> extensions; for example, RFC7838.  Likewise, the set of servers for which a connection is considered authoritative can be changed with a </ins> protocol extension like RFC8336. Providing a response from a non-authoritative source, such as a
Code change:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Related discussion:
text: The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other <del> namespaces that might be controlled by the same server.  It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </del> <ins> namespaces that might be controlled by the same server (field.host). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces, or at least prepared to reject requests that appear to have been misdirected.  A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. </ins> For example, if a network attacker causes connections for port N to be received at port Q, checking the target URI is necessary to ensure
Code change:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Related discussion:
text: and <del> fields ought to be implemented by all HTTP/1.x implementations whether or not they advertise conformance with HTTP/1.1. </del> <ins> fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1. </ins> New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients
Code change:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Related discussion:
text: The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple <del> host names on a single IP address. </del> <ins> host names. </ins> <del> Since the Host field value is critical information for handling a request, a user agent SHOULD generate Host as the first field in the header section. </del> <ins> In HTTP/2 RFC7540 and HTTP/3 HTTP3, the Host header field is, in some cases, supplanted by the ":authority" pseudo-header field of a request's control data. The target URI's authority information is critical for handling a request.  A user agent SHOULD generate Host as the first field in the header section of a request unless it has already generated that information as an ":authority" pseudo-header field. </ins> For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: <del> Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server.  An interception proxy is particularly vulnerable if it relies on the Host field value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </del> <ins> Since the host and port information acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the host and port information for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. </ins> 7.1.3.
Code change:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Related discussion:
text: validation requests for the content might only be applicable along the same request path (through the same proxies). <del> The 203 response is similar to the Warning code of 214 Transformation Applied (field.warning), which has the advantage of being applicable to responses with any status code. </del> A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).
Code change:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Related discussion:
text: implementing such verification can be difficult (see Georgiev). Authority for a given origin server can be delegated through protocol <del> extensions; for example, RFC7838.  Likewise, the set of servers that a connection is considered authoritative for can be changed with a </del> <ins> extensions; for example, RFC7838.  Likewise, the set of servers for which a connection is considered authoritative can be changed with a </ins> protocol extension like RFC8336. Providing a response from a non-authoritative source, such as a
Code change:
by changing DL to a table and tweaking description of HEAD.
"HEAD: the same representation as GET, but without the representation data;" Should that be "payload data"?
No, that's correct, but I will tweak it slightly: HEAD: the same representation as GET, but without transferring the representation data;
Note that the context is a discussion of what representation is included in a 200 response, which is why we are talking about representation data here instead of payload data.

Related discussion:
text: with the registration procedure of status.code.registry and the status code values summarized in the following table. <del> Additionally, please update the following entry in the Hypertext Transfer Protocol (HTTP) Status Code Registry: </del> 18.4. This specification updates the HTTP related aspects of the existing
Code change:
"The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [Caching]), which has the advantage of being applicable to responses with any status code." But then we have removed "Warning"...
I think we can just remove this text; if it's important, we can refer to 7234 and mention that it's deprecated.
I say just remove the sentence.

Related discussion:
text: validation requests for the content might only be applicable along the same request path (through the same proxies). <del> The 203 response is similar to the Warning code of 214 Transformation Applied (field.warning), which has the advantage of being applicable to responses with any status code. </del> A 203 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness).
Code change:
" For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC8446]) prior to exchanging any credentials." This originates from RFC 7235. Nowaday, shouldn't we instead say "require HTTPS"?
I think it should be ... authentication require a secured connection prior to exchanging any credentials (ref target="URL"). and x:ref around the term "secured" (defined in that section).

Related discussion:
text: HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of <del> fields.  In other words, if a server limits access to authenticated users using this framework, the server needs to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used.  For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", RFC8446) prior to exchanging any credentials. </del> <ins> fields.  Services that depend on individual user authentication require a connection prior to exchanging credentials (https.uri). </ins> 17.15.2.
Code change:
" Considerations related to message syntax, parsing, and routing are discussed in Section 11 of [Messaging]." Make clear that these are only the HTTP/1.1 considerations. Optionally add links for HTTP/2 and HTTP/3.

Related discussion:
text: This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet. <del> Considerations related to message syntax, parsing, and routing are discussed in Messaging-security.considerations. </del> <ins> Considerations related to caching are discussed in Caching- security.considerations and considerations related to HTTP/1.1 message syntax and parsing are discussed in Messaging- security.considerations. </ins> The list of considerations below is not exhaustive.  Most security concerns related to HTTP semantics are about securing server-side
Code change:
"This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation." replace by just "fields"?
I think it's useful to retain the current text, because those phrases are more likely to be recognised by readers coming to the document.
No real opinion, but it should be rewritten anyway: This document defines the semantics shared by all versions of the Hypertext Transfer Protocol (HTTP), including its architecture, terminology, and core protocol elements, along with the "http" and "https" identifier schemes. It could go on from there to describe the core elements, and maybe the core features as well, but shrug.

Related discussion:
text: The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information <del> systems.  This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation. </del> <ins> systems.  This document defines the semantics shared by all versions of HTTP, including its architecture, terminology, core protocol elements, and extensibility mechanisms, along with the "http" and "https" Uniform Resource Identifier (URI) schemes. </ins> This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: provides a list of representations for the user agent to choose from, and "request payload" negotiation, where the user agent selects the representation for a future request based upon the server's stated <del> preferences in past responses.  Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in </del> <ins> preferences in past responses. Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary.  These patterns are not mutually exclusive, and each has trade-offs in </ins> applicability and practicality. Note that, in all cases, HTTP is not aware of the resource semantics.
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: decimal point.  User configuration of these values ought to be limited in the same fashion. <del> 12.1.1.3. </del> <ins> 12.4.3. </ins> Most of these header fields, where indicated, define a wildcard value <del> ("*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. </del> <ins> ("*") to select unspecified values.  If no wildcard is present, values that are not explicitly mentioned in the field are considered unacceptable, except for within where it means the variance is unlimited. 12.5. </ins> <del> 12.1.2. </del> <ins> 12.5.1. </ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: would cause the following values to be associated: <del> 12.1.3. </del> <ins> 12.5.2. </ins> The "Accept-Charset" header field can be sent by a user agent to indicate its preferences for charsets in textual response content.
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: The special value "*", if present in the Accept-Charset header field, matches every charset that is not mentioned elsewhere in the field. <del> 12.1.4. </del> <ins> 12.5.3. </ins> The "Accept-Encoding" header field can be used to indicate preferences regarding the use of content codings (content.codings).
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: response when the request payload was big enough to justify use of a compression coding but the client failed do so. <del> 12.1.5. </del> <ins> 12.5.4. </ins> The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: does not provide such control to the user MUST NOT send an Accept- Language header field. <del> 12.2. With (a.k.a., ), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations.  If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response.  Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu. Note that the above refers to representations of the response, in general, not representations of the resource.  The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a response to a GET request). A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred.  For example, the alternatives listed in responses with the and status codes include information about the available representations so that the user or user agent can react by making a selection. Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage. Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension. 12.2.1. </del> <ins> 12.5.5. </ins> The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might
Code change:
initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...

Related discussion:
text: it considers the variance less significant than the performance cost of Vary's impact on caching. <del> 12.3. When content negotiation preferences are sent in a server's response, the listed preferences are called because they intend to influence selection of an appropriate payload for subsequent requests to that resource.  For example, the (field.accept) and (field.accept-encoding) header fields can be sent in a response to indicate preferred media types and content codings for subsequent requests to that resource. Similarly, RFC5789 defines the "Accept-Patch" response header field which allows discovery of which content types are accepted in PATCH requests. </del> 13. A conditional request is an HTTP request with one or more request
Code change:
(this text is present in RFC 7233 as well) "A valid entity-tag can be distinguished from a valid HTTP-date by examining the first two characters for a DQUOTE." Hm, no. If we want to properly handle weak etags, we either need to inspect three characters (actually position 0 and 2) for DQUOTE, or check pos 0 for DQUOTE or pos 1 for "/". If we're not interested in weak etags, checking the first character is sufficient.

Related discussion:
text: can be distinguished from a valid <del> by examining the first two characters for a DQUOTE. </del> <ins> by examining the first three characters for a DQUOTE. </ins> If the validator given in the If-Range header field matches the current validator for the selected representation of the target
Code change:
"The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the protocol." "URL left out altogether..." ?
(need to check where the fix went)

Related discussion:
text: The status codes listed below are defined in this specification.  The reason phrases listed here are only recommendations -- they can be <del> replaced by local equivalents without affecting the protocol. </del> <ins> replaced by local equivalents or left out altogether without affecting the protocol. </ins> Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,