jiebi/CodeConvo huggingface dataset:
Code change:
with a value that is one less than the current length of the selected representation). <del> A client can request the last N bytes of the selected representation using a </del> <ins> A client can request the last N bytes (N > 0) of the selected representation using a </ins> .  If the selected representation is shorter than the specified

Related discussion:
text: In 416 status code section, remove duplicate definition of what makes a range satisfiable and refer instead to each range unit's definition. In sections on bytes ranges and Range, clarify that a selected representation of zero length can only be satisfiable as a suffix range and that a server can still ignore Range for that case.
Regarding byte ranges, an empty (zero-length) representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. I would like to see an update to the RFC which explicitly resolve this self-contradiction in whatever way seems appropriate. The following is one suggestion, but there may be others: I would like to suggest explicitly specifying that an empty 200 response should be returned in this case. It is the simplest solution to the current self-contradiction in the RFC, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information about the representation to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations (as opposed to more intricate solutions). Perhaps the following can be added at the end of section 3.1: "If all of the preconditions are true and the target representation length is zero, the server SHOULD send a 200 (OK) response." (someone in the discussion preferred this to be a MUST, but the SHOULD might be more in line with the previous sections and backward-compatibility if some implementations resolved this in some other way.) I raised this in the mailing list a while back, and it got some discussion and support but did not get officially resolved. More recently I reported it as errata but it was rejected as not being an erratum and redirected here (I apologize - didn't realize issues moved to github, and still not sure what the distinction is :-) ), so here it is, raised again. All suggestions and feedback are welcome.
So how do we get this fixed? There was a discussion about it in the IETF mailing list, in which others confirmed the issue. I opened an errata, but it was closed saying it's not an errata. I was pointed here to open the issue, but got no response in 9 months so far. What can I do to get a response or to help move this forward?
Code change:
with a value that is one less than the current length of the selected representation). <del> A client can request the last N bytes of the selected representation using a </del> <ins> A client can request the last N bytes (N > 0) of the selected representation using a </ins> .  If the selected representation is shorter than the specified

Related discussion:
text: If the powers that be don't agree that the issue requires fixing, it would be nice to get such feedback explicitly and discuss it. If this issue tracker is inactive and the issue should be posted somewhere else, I'd be happy to do it, just point me in the right direction.
We're not currently working on a revision to this document, so an official answer won't be forthcoming for a while. In the meantime, the best thing to do is to discuss it on list, taking the advice you get there. See Roy's response in particular: URL
Just looked this up to see if it's been forgotten... can I assume from the new labels that it's on someone's todo list and will be looked at eventually, even if it'll take a while longer? (btw the link your referenced actually contains another bug, so I'm referring to both, i.e. the whole discussion).
NAME Thanks for resolving the issues! Better late than never :-) Indeed now there is no longer a self-contradition in the spec, but I'm curious, why did you change your mind since the discussion in the link above, where you seemed to prefer a 200 result for an empty resource (even suggesting a MUST), to the current fix which leans towards the 416 by defining it explicitly as unsatisfiable (with the option 200 downgraded to MAY), or at best makes it a tossup which option servers will implement? Did you have any specific pros/cons or use cases in mind? I guess I still prefer a 200 as the simpler and more straightforward solution :-)
An implementation can choose to send 200. Making that a SHOULD or MUST would be a new normative requirement that isn't justifiable for interop.
ok. Thanks again!
Code change:
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement RFC7838 for a protocol identifier that uses <del> TLS, such as "h2" RFC7540, or "http/1.1" RFC7301.  Note that HTTP/1.1 requests MUST use the absolute form (see Section 5.3.2 of RFC7230). </del> <ins> TLS, such as "h2" RFC7540.  Such a protocol MUST include an explicit indication of the scheme of the resource.  This excludes HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute form of a URI in requests to origin servers (see Section 5.3.1 of RFC7230). </ins> A client that receives such an advertisement MAY make future requests <del> intended for the associated origin (RFC6454) to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in auth. </del> <ins> intended for the associated origin RFC6454 to the identified service (as specified by RFC7838), provided that the alternative service opts in as described in opt-in. </ins> A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an

Related discussion:
text: I tried to make this work, but NAME is right: this is entirely a transport decision and given that our best option was to violate a MUST in RFC 7230, that's too hard. This just says that HTTP/1.1 is no good because we can't include the scheme (because RFC 7230 says we can't). I almost made this h2-specific, but then remembered that there might be another protocol that has favourable properties.
It's official - MT says "HTTP/1.1 is no good."
Code change:
3.2. <del> This document defines a workload identity as a URI RFC3986.  This URI is used in the subject fields in the certificates and tokens defined later in this document.  This specification treats the URI as opaque. The format of the URI and the namespace for the URI are at the discretion of the deployment at large.  Other specifications may define specific URI structures for particular use cases.  An example of a defined identity format is the SPIFFE ID [1]. A workload identity only has meaning within the scope of a specific issuer.  Two identities of the same value issued by different issuers may or may not refer to the same workload.  In order to avoid collisions identity URIs SHOULD specify, in the URI's "authority" field, the trust domain associated with an issuer that is selected from a global name space such as host domains.  However, the validator of an identity credential MUST make sure that they are using the correct issuer credential to verify the identity credential and that the issuer is trusted to issue tokens for the defined trust domain. </del> <ins> This document defines a workload identifier as a URI RFC3986.  This URI is used in the subject fields in the certificates and tokens defined later in this document.  The URI MUST meet the criteria for the URI type of Subject Alternative Name defined in Section 4.2.1.6 of RFC5280. In addition the URI MUST include an authority that identifies the trust domain within which the identifier is scoped.  The trust domain SHOULD be a fully qualified domain name belonging to the organization defining the trust domain to help provide uniqueness for the trust domain identifier.  The scheme and scheme specific part are not defined by this specification.  An example of an identifier format that conforms to this definition is SPIFFE ID [1].  While the URI encoding rules allow host names to be specified as IP addresses, IP addresses MUT NOT be used to represent trust domains except in the case where they are needed for compatibility with existing naming schemes. </ins> 4.

Related discussion:
text: Revised the workload identity section to align with RFC 5280 and include trust domain. Aligns closely with SPIFFE, but allows other schemes to be defined.
Code change:
Server MUST reject the request (do we need to define a specific error code for that?). <del> 9.4.2. </del> <ins> 9.5.2. </ins> It may be possible to use other proof of possession mechanisms to sender constrain access and refresh tokens.  Defining these mechanisms are out of scope for this specification. <del> 9.4.3. </del> <ins> 9.5.3. </ins> PoP binding of device session parameter <del> 9.5. </del> <ins> 9.6. </ins> When there is more than one 1st-party native applications supported by the AS, then it is important to consider a number of additional risks.  These risks fall into two main categories: Experience Risk and Technical Risk which are described below. <del> 9.5.1. </del> <ins> 9.6.1. </ins> Any time a user is asked to provide the authentication credentials in user experiences that differ, it has the effect of increasing the likelihood that the user will fall prey to a phishing attack because they are used to entering credentials in different looking <del> experiences.  When multiple native applications are support, the </del> <ins> experiences.  When multiple native applications are supported, the </ins> implementation MUST ensure the native experience is identical across all the 1st party native applications.

Related discussion:
text: I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.
Code change:
Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version <del> as its value to its requests.  Its ABNF is </del> <ins> as its value to its requests.  The "Upload-Draft-Interop-Version" field value is an Integer. </ins> Server implementations of draft versions of the protocol MUST NOT send a "104 (Upload Resumption Supported)" informational response

Related discussion:
text: See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.
Code change:
A response's age can be calculated in two entirely independent ways: <del> These are combined as </del> <ins> The corrected_age_value MAY be used as the corrected_initial_age.  In circumstances where very old cache implementations that might not correctly insert </ins> <del> unless the cache is confident in the value of the header field (e.g., because there are no HTTP/1.0 hops in the header field), in which case the corrected_age_value MAY be used as the corrected_initial_age. </del> <ins> are present, corrected_initial_age can be calculated more conservatively as </ins> The current_age of a stored response can then be calculated by adding the time (in seconds) since the stored response was last validated by

Related discussion:
text: ... it's just deployments of very very old caches that would be of concern here. Given how unlikely this is in 2020, how broken they would be for other reasons, and the prevalence of HTTPS, it seems safe to modify these statements.
Is this warning still relevant? If we want to keep it, I think we need to qualify it; e.g., "A few old HTTP/1.0 caches that are unlikely to be used on the open Internet..." Similar text in cc: no-cache.
I think the warnings can be removed.
Code change:
include complex subnetworks where the minimum delay changes over various time scales, resulting in a non- stationary minimum delay. <del> This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes.  A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation). Variation also arises when traffic with a higher priority DSCP pre- empts transmission of traffic with a lower class.  In these cases, the delay varies as a function of external factors, and attempting to infer congestion from an increase in the delay results in reduced throughput.  This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects. </del> <ins> Varying delay occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc.  It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes.  A node might then have to buffer data until an assigned transmission opportunity or until the physical path changes (e.g., when the length of a wireless path changes, or the physical layer changes its mode of operation).  Variation also arises when traffic with a higher priority DSCP pre-empts transmission of traffic with a lower class. In these cases, the delay varies as a function of external factors, and attempting to infer congestion from an increase in the delay results in reduced throughput.  This variation in the delay over short timescales (jitter) might not be distinguishable from jitter that results from other effects. </ins> A proposed congestion control algorithm SHOULD be evaluated to ensure its operation is robust when there is a significant change in the

Related discussion:
text: Suggested final edits. do not infer that BBR is "fixed", but rather say that it contains a "fix" for this. don't overstate the importance:-) fix to start by saying what the para is about (i.e. the section title).
Code change:
7. Transfer coding names are used to indicate an encoding transformation <del> that has been, can be, or might need to be applied to a payload body in order to ensure "safe transport" through the network.  This </del> <ins> that has been, can be, or might need to be applied to a payload's data in order to ensure "safe transport" through the network.  This </ins> differs from a content coding in that the transfer coding is a property of the message rather than a property of the representation that is being transferred. <del> Parameters are in the form of a name=value pair. </del> All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined in transfer.coding.registry.  They are used in the <del> (field.te) and </del> <ins> (field.transfer-encoding) and </ins> <del> (field.transfer-encoding) header fields. </del> <ins> (field.te) header fields (the latter also defining the "transfer- coding" grammar). </ins> 7.1. <del> The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </del> <ins> The chunked transfer coding wraps payload data in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields.  Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </ins> retain connection persistence and the recipient to know when it has received the entire message.

Related discussion:
text: I think we discussed this last week and Julian has pending changes to be made before review.
This just moves the ABNF, not the definition of the transfer codings.
This is the remaining ABNF production that Semantics imports from Messaging (for the definition of "TE"). Maybe we should move the production to messaging, reversing the dependency.
Discussed on call; worth a try.
URL out that there are a few more things to consider: Semantics currently claims there are regular parameters here, but transfer-parameter is special wrt BWS should we move the special case of "trailers" in the grammar into prose? In any case, what would it mean to have a ranking on "trailers"? Invalid, thus ignore? "t-ranking" seems to duplicate "weight"
Fine to merge, but shouldn't we also move the extensibility and IANA registry sections?
Code change:
The client performs token exchange as defined in RFC8693 with the authorization server for its own domain (e.g., Domain A) in order to <del> obtain an authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </del> <ins> obtain a JWT authorization grant that can be used with the authorization server of a different domain (e.g., Domain B) as specified in section 1.3 of RFC6749. </ins> 2.4.1.

Related discussion:
text: when "authorization grant" refers to the actual JWT being passed around, it is clearer to call it "JWT authorization grant". RFC6749 uses "authorization grant" to refer to the general concept of any grant
Code change:
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

Related discussion:
text: 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...
Code change:
not to be needed for single-entry lists). Although it has been back-ported to many implementations, some <del> HTTP/1.0 caches will not recognize or obey this directive.  Also, no- cache response directives with field names are often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented. </del> <ins> HTTP/1.0 caches will not recognize or obey this directive.  Also, the qualified form of the directive is often handled by caches as if an unqualified no-cache directive was received; i.e., the special handling for the qualified form is not widely implemented. </ins> 5.2.2.4.

Related discussion:
text: This is related to issue On the flight back from Switzerland, I spent time looking at the cache directives and how they differ from the descriptions in RFC2616. I worked out these problems and drafted a pull request, but I haven't checked whether we changed these deliberately for RFC7234, or if the distinctions just got lost in the rewrite. In any case, I think this is an improvement, but definitely needs reviews.
This ended up being an editorial change between drafts because the only normative changes were already noted for and , and this is just rewording what we had for .
From : Both state that a (depending on context private, shared or both types of) "cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable". To my understanding, this does not intend to override the requirements from the "Storing Responses in Caches" section (URL) altogether. Instead, I would assume that it only refers to the condition "has a status code that is defined as heuristically cacheable" in that section (or, as it was stated in RFC7234, "has a status code that is defined as cacheable by default")? Would it make sense to amend the list of conditions in that section, appending to the "the response either..." second-level list: "contains a private response directive if the cache is not shared"?
OP here
lists some directives that allow responses with Authentication to be stored, but some of those directives' definitions do not mention this.
I think this should also be added for ; see .
I think this issue needs to be reopened and the specification text reverted to something more like what was in RFC2616. That spec specifically requires public be present to allow responses to a request with Authorization to be stored by a shared cache, regardless of must-revalidate or proxy-revalidate. This is not implied by those other directives.