jiebi/CodeConvo huggingface dataset:
Code change:
to be removed ... it was just leftover from the old org. Also, we should call it Request Context Fields.

Related discussion:
text: 10.1. <del> A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing.  These fields act as request modifiers, similar to the parameters on a programming language method invocation. </del> The request header fields below provide additional information about the request context, including information about the user, user agent, and resource behind the request.
Code change:
"If the client has an outstanding request in transit, the client MAY repeat that request on a new connection."
I don't think this needs to be changed (connection is a defined term), but if you can think of some other way to say that the 408 implies partial receipt of the last request (which means the connection gone broke) then go ahead.
Suggestion:
+1

Related discussion:
text: The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del> <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.
Code change:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Related discussion:
text: field-components defines some generic syntactic components for field values. <del> The rule below is defined in Messaging; </del> This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in RFC6365.
Code change:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Related discussion:
text: transfer codings the client is willing to accept in the response. The TE field value consists of a list of tokens, each allowing for <del> optional parameters (as described in parameter). </del> <ins> optional parameters (except for the special case "trailers"). </ins> 10.1.5.
Code change:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Related discussion:
text: A server MAY ignore the Range header field.  However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers <del> and partial retrieval of large representations.  A server MUST ignore a Range header field received with a request method other than GET. </del> <ins> and partial retrieval of large representations. A server MUST ignore a Range header field received with a request method which is unrecognized or for which range handling is not defined.  For this specification, is the only method for which range handling is defined. </ins> An origin server MUST ignore a Range header field that contains a range unit it does not understand.  A proxy MAY discard a Range
Code change:
: "A server MUST ignore a Range header field received with a request method other than GET." : "Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too."
I can see why someone might want to use it with SEARCH as well, though they would more likely use a page parameter. I can't think of any other use case.
FWIW, that's exactly how it was used by MS in Exchange SEARCH: We need to decide which of the statements in our spec is correct.
Huh, that's news for me. We could have used that example for Range extensions.
Change requirement to MUST ignore Range when not defined for that method or the method is unrecognized.

Related discussion:
text: The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del> <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.
Code change:
Note that I also cleaned up the surrounding paragraph and removed parentheses from around the statement that the response always terminates after the header section.
currently links to "Message Payload", but that is not that helpful in order to find out what fields actually are "payload header fields".
Note. We currently say: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 6.4) MAY be omitted." URL would change this to: "The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., Transfer-Encoding) MAY be omitted." (me confused by that)
I should probably just list them all. Content-Length and Transfer-Encoding are the obvious ones, but I would have to go through the spec to be sure there are not more. The reason for this is that servers do not generate the body on HEAD responses, so the fields that are defined while buffering the first 8K of body (when they can still be sent as headers) are not sent on HEAD responses. Maybe we should just say that.

Related discussion:
text: 9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send payload data in the response (i.e., the response terminates at the end of the header section).  The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., </del> <ins> send payload data in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about the without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications. The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the payload data.  For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain </ins> <del> ) MAY be omitted. HEAD is used to obtain metadata about the </del> <ins> and </ins> <del> without transferring the representation data.  It is often used to test hypertext links for validity, accessibility, and recent modification. </del> <ins> fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the payload data for a HEAD request, since HEAD is usually requested for the sake of efficiency. </ins> A payload within a HEAD request message has no defined semantics; sending payload data in a HEAD request might cause some existing
Code change:
"This directive is NOT a reliable or sufficient mechanism for ensuring privacy." Should be lowercase. Could use .
also in 5.2.2.4

Related discussion:
text: effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del> <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already
Code change:
"This directive is NOT a reliable or sufficient mechanism for ensuring privacy." Should be lowercase. Could use .
also in 5.2.2.4

Related discussion:
text: effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del> <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> 5.2.2.5.
Code change:
"Additionally, specific HTTP versions can use it to indicate the transfer codings the client is willing to accept in the response." If we phrase it this way, we'd have to say somewhere in Semantics what transfer codings actually are. Or we decide that they are specific to HTTP/1.*, rephrase this, and link to Messaging.

Related discussion:
text: member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del> <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").
Code change:
Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last

Related discussion:
text: Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a <del> given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries, eventually being defined as HTTP/1.0 RFC1945. </del> <ins> given pathname.  As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries.  These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see RFC1945). </ins> HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging
Code change:
Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last

Related discussion:
text: member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del> <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").
Code change:
Good point.
For .
URL be good to have tests...
goes back to URL
sent mail: URL
See URL
Proposal: leave weight in ABNF for consistency with other Accept-* fields change second requirement (on recipients) not to rely on "q" being last

Related discussion:
text: subtypes of that type.  The media-range can include media type parameters that are applicable to that range. <del> Each media-range might be followed by zero or more applicable media type parameters (e.g., </del> <ins> Each media-range might be followed by optional applicable media type parameters (e.g., ), followed by an optional "q" parameter for indicating a relative weight (quality.values). </ins> <del> ), an optional "q" parameter for indicating a relative weight (quality.values), and then zero or more extension parameters.  The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets. </del> <ins> This specification does not define "accept parameters" following the special "q" parameter, as was done in earlier editions.  Senders using weights SHOULD send "q" last (after all media-range parameters).  Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering. </ins> The example
Code change:
Im ok with replacing the 0.9 reference (although having the link here acknowledges where 0.9 came from, right). The idea was to mention 0.9 in the context of RFC 1945 as well as that is an IETF document which actually describes what 0.9 is.
URL out that RFC 1945 defines HTTP/0.9 as well (see URL). Maybe we should add this reference, or replace the existing one.
We do reference 1945 for HTTP/1.0. Revised proposal: just mention that that RFC describes 0.9 as well.

Related discussion:
text: Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a <del> given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries, eventually being defined as HTTP/1.0 RFC1945. </del> <ins> given pathname.  As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries.  These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see RFC1945). </ins> HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging
Code change:
This issue is from a related discussion on Apache httpd, which was trying to comply by sending a 504 even though the revalidation error was a 502. That's nuts. The current text for says: However, if a proxy/gateway received a 5xx response while trying to revalidate, this requirement forces it to toss that information and supply a useless 504 instead. That isn't desirable. The entire purpose of this requirement is to make sure that the cache does not respond with its stale entry. Hence, any 5xx code is sufficient.
To fill in more detail, the change in question is this one: URL And covers the wide question of "which 5xx response is returned in low level network failure cases, such as DNS error, connection refused, connection timed out, etc". The commit message referred to RFC2616 14.9.4 Cache Revalidation and Reload Controls, but this seems to be a wider issue.
Yes, that MUST is too strong; I suspect it's there to make the mechanism reliable, not override other potential status codes. Will work on a PR.

Related discussion:
text: The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a <del> cache MUST obey the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate a </del> <ins> cache MUST NOT ignore the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate an error response rather than reuse the stale response.  The generated status code SHOULD be </ins> <del> response rather than reuse the stale response. </del> <ins> unless another error status code is more applicable. </ins> The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could cause
Code change:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Related discussion:
text: the namespace for HTTP field names. Any party can request registration of a HTTP field.  See <del> considerations.for.new.field.values for considerations to take into account when creating a new HTTP field. </del> <ins> considerations.for.new.fields for considerations to take into account when creating a new HTTP field. </ins> The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at <https://www.iana.org/assignments/http-fields/>.
Code change:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Related discussion:
text: 16.3.2. <ins> HTTP header and trailer fields are a widely-used extension point for the protocol.  While they can be (and often are) used in an ad hoc fashion, fields that are widely used need to be more carefully documented, to ensure interoperability. In particular, authors of specifications defining new fields are advised to consider and, where appropriate, document the following aspects: Request header fields have additional considerations that need to be documented if the default behaviour is not appropriate: 16.3.2.1. </ins> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on
Code change:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Related discussion:
text: To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that <del> includes its name (or an abbreviation) as a prefix; for example, if </del> <ins> includes that use (or an abbreviation) as a prefix; for example, if </ins> the Foo Application needs a Description field, it might use "Foo- Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.
Code change:
Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...

Related discussion:
text: prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. <del> 16.3.3. </del> <ins> 16.3.2.2. A major task in the definition of a new HTTP field is the specification of the field value syntax: what senders should generate, and how recipients should infer semantics from what is received. Authors are encouraged (but not required) to use either the ABNF rules in this specification or those in RFCSTRF to define the syntax of new field values. Authors are advised to carefully consider how the combination of multiple field lines will impact them (see field-order).  Because senders might send erroneously send multiple values, and both intermediaries and HTTP libraries can perform combination automatically, this applies to all field values -- even when only a single value is anticipated. Therefore, authors are advised to either delimit values that contain commas (e.g., with the rule; see quoted.strings, or the String data type in RFCSTRF), or encode or escape them.  This ensures that commas in the payload of the field value are not confused with those used to delimit list values. For example, the field value only allows commas inside quoted strings, and so can be reliably parsed, even when multiple values are present.  The field value provides a counter-example that should not be emulated: because URIs can include commas, it is not possible to reliably distinguish between a single value that includes a comma from two values. </ins> <del> Authors of specifications defining new fields are advised to consider documenting: </del> <ins> Authors of fields with a singleton value (see field-values) are additionally advised to document how to treat messages where the multiple members are present (a sensible default would be to ignore the field, but this might not always be the right choice). </ins> 16.4.