jiebi/CodeConvo huggingface dataset:
Code change:
9.5.20. <del> The 422 (Unprocessable Entity) status code indicates that the server understands the content type of the request entity (hence a </del> <ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a </ins> <del> status code is inappropriate), and the syntax of the request entity is correct but was unable to process the contained instructions.  For example, this error condition may occur if an XML request body </del> <ins> status code is inappropriate), and the syntax of the request payload is correct, but was unable to process the contained instructions. For example, this status code can be sent if an XML request payload </ins> contains well-formed (i.e., syntactically correct), but semantically <del> erroneous, XML instructions. </del> <ins> erroneous XML instructions. </ins> 9.5.21.

Related discussion:
text: …se) (see )
I chose "Payload" in the reason phrase for consistency with 413... We do use "enclosed representation" in many other places, such as in the definitions of PUT, 401, and Content-Location. Maybe use "payload" throughout? (I guess we have way more terminology to clean up)
NAME it's not incorrect, but sure we can tune things even more...
The term entity to be dismissed, in favor of It's used here, as 422 is C&P from webdav URL
The only thing that causes me concern here is that you're using both "representation" and "payload" in a manner that's technically correct (I think), but is likely to cause readers confusion about the difference between the two. We don't use "enclosed representation" elsewhere, but we do use "representation data enclosed in the payload body" and "enclosed payload body" (which seems odd to me). It would be very good if we could clarify and consistently use this terminology (here or in another bug). PS I was very tempted to ask you to move the prose tuning to a separate PR, but I won't.
Code change:
Recommended HTTP status code: <del> 3.34. </del> <ins> 3.33. </ins> Name: proxy_internal_error

Related discussion:
text: Signed-off-by: Piotr Sikora
cc NAME
This field uses for a specific purpose, but that's already in the generic parameters. Suggest or similar. /cc NAME
Looks like has the same issue. Should we use for both? Note that the identifier is context-based, since if proxy configured SHA256-based validation, then would be , if it configured SPKI-based validation, then would be , etc. We could also use and instead of (and for ), but that doesn't seem very future-proof. What do you think?
Hmm, that's awkward. Maybe two fields? E.g., : [, ... ] : ... Is there a registry we can refer to, maybe?
I'm afraid that there isn't any registry that we can refer to, at least none that I know of. (opaque type) and (opaque value) seem a bit awkward. Wouldn't it be easier to just have and params? Also, in Envoy, we actually configure list of acceptable and values, and matching against any of them works, so we should probably emit both of them anyway. I could envision merging and into a single status type that lists all 3 params, e.g. See . What do you think?
Better than what we had :)
Code change:
details. Some Verifiers may systematically resolve Issuer DIDs to fetch the <del> latest corresponding DID documents.  This behaviour strictly enforces </del> <ins> latest corresponding DID documents.  This behavior strictly enforces </ins> the revocation of compromised keys: once the Issuer has updated its Statement to remove a key identifier, all Signed Statements include the corresponding "kid" will be rejected.  However, others may

Related discussion:
text: With no content changes (beyond spelling), build success, and to assure other PRs aren't blocked, I'm merging as editor.
+1
Code change:
header field in the header section of that message to indicate which fields might be present in the trailers. <del> 5.6.4. </del> <ins> 5.6.5. </ins> The "TE" header field in a request can be used to indicate that the sender will not discard trailer fields when it contains a "trailers"

Related discussion:
text: Does this mean it's now valid to interleave HTTP/2 DATA frames and HEADER frames?
Does this mean we cannot implement this on HTTP/2?
The feature was removed during WGLC, but no -- it would have required a new frame type.
Okay, so chunk extensions remains a unique feature of HTTP/1 chunked encoding and there is no plan to expand that further?
Yes.
As discussed in and URL, mid-stream trailers (i.e., those that arrive before the end of the payload body) are interesting. A few things to discuss: [ ] What are some potential use cases?[ ] We recently stopped automatically combining trailers into headers, as that created a lot of issues. What about these -- are they yet again distinct from trailers as well as headers? Or can they be "downgraded" into trailers automatically? In other words, when transitioning from a hop that supports these from one that doesn't, are they just dropped onto the floor?[ ] Related - is the expectation that implementations will create separate APIs for these, or would it be that trailers are just available / writable early?[ ] What relationship does one of these have to the payload body? E.g., could I write one that "knows" exactly where in the body it occurs, so that it could sign a chunk of the body relative to it? Or could a handling implementation change its ordering in relation to body bytes?
Some preliminary considerations. Incremental checksums eg. Service management (eg. convey the ETA of the transfer, ...) Sending signatures of partial body (in mid-stream) has some complexities respect to sending a signature of the whole message in the header/trailer section, and requires a security URL trailers, when used for integrity can't be dropped without informing the user agent They probably need to be defined as 1#field-item because mid-stream trailers will be sent multiple times (eg. one per chunk) Whenever they are tied to the partial transmitted representation, they will eventually be unuseful when merged, unless they have some associative propertyThey will be especially useful when tied to a portion of the body They will be significantly less useful when not tied to a portion of the body
Potential use cases mostly limited to long-lived streaming traffic, i.e.
Code change:
header field in the header section of that message to indicate which fields might be present in the trailers. <del> 5.6.4. </del> <ins> 5.6.5. </ins> The "TE" header field in a request can be used to indicate that the sender will not discard trailer fields when it contains a "trailers"

Related discussion:
text: long-lived "uploading/downloading" in-band signaling support such as load reporting, app-level flow-control, authn update etc Semantics trailers are a special case of mid-stream metadata, e.g. only trailers are able to convey the status of the entire transaction or the entire resource (body) our experience is that in-order delivery is useful and often assumed, since the underlying transport (for HTTP body) is in-order and reliable. Out-of-order metadata is likely a use case for connection-level metadata, IMO with the above assumption on in-order delivery, you really only need one API for delivering in-stream or trailer metadata Multi-part without in-stream metadata, you would have to use multipart (with all the overhead) for structured data, the original content-type can be preserved, e.g. JSON stream; and for media data, the content-type may have to be application/octet-stream
Copying over the questions from NAME over in URL, as they are good ones:
The semantic model of trailers is that they provide additional metadata that may (or may not) be useful to recipients but was not available prior to the initial body data sent. How the are useful and what they might contain would be defined by the field name. A recipient is free to drop the trailer metadata. A mid-stream trailer frame would have the same role in flow control as a HEADERS frame, which is none at the current time. The proposed frames would not have any specific position, but the values inside trailer fields might identify specific positions (on their own, regardless of framing). A cache would either drop the values or store them separately as trailer fields in the order received.
HTTP/2's flow control only cares about DATA frames. But all frames are subject to TCP's flow control. In HTTP/3, all frames are sent on streams which is subject to QUIC's flow control. Responding to the original question, I don't know what a "new form of flow control" would look like and I don't see how one would improve things.
What's the minimal change that would need to happen to semantics to enable this in a future version of HTTP (or an extension to an existing one)?
I think you would need to make "trailer part" less special, and simply say that a version of HTTP can define a way to carry additional field sections during or after the body.
Code change:
header field in the header section of that message to indicate which fields might be present in the trailers. <del> 5.6.4. </del> <ins> 5.6.5. </ins> The "TE" header field in a request can be used to indicate that the sender will not discard trailer fields when it contains a "trailers"

Related discussion:
text: H1-H3 currently define a way to carry only one such block, but an extension could provide more.
Code change:
different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 6.1.2 of I-D.ietf-httpbis-semantics) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </del> <ins> no content codings (see Section 6.1.2 of SEMANTICS) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </ins> 1.3.

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
initial representation for the target resource. An origin server that receives an If-None-Match header field MUST <del> evaluate the condition prior to performing the method (evaluation). </del> <ins> evaluate the condition as per evaluation prior to performing the method. </ins> To evaluate a received If-None-Match header field:

Related discussion:
text: this is the part of URL related to -semantics
Continueing the discussion from URL Looking at the next text in context: To me it's unclear why we are calling out bare CR here, isn't the situation the same for LF and CRLF?? This also is not a new requirement, the ABNF does not allow CR and friends in field-value, and in 3.2 we say "A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules." The subsequent paragraph talks about whitespace, and it may not be clear to everyone which characters we are referring to here (not the ones listed in Section 1.2.1 "Whitespace", correct?)
Proposal:
NAME ?
(forked from )
A bit iffy given the sentence above it, but okay.
Code change:
used. <del> OPTIONAL.  JSON array containing a list of the OAuth 2.0 Bearer Token RFC6750 presentation methods that this protected resource supports.  Defined values are "["header", "body", "query"]", </del> <ins> OPTIONAL.  JSON array containing a list of the supported methods of sending an OAuth 2.0 Bearer Token RFC6750 to the protected resource.  Defined values are "["header", "body", "query"]", </ins> corresponding to Sections 2.1, 2.2, and 2.3 of RFC 6750.

Related discussion:
text: cc NAME
From Pieter's review: Since "presentation methods" has come to have a new meaning. The language above is consistent with the language used in 6750.
The text is clear and brings better alignment with the name of the parameter.
Code change:
5. A protected resource MAY use a "WWW-Authenticate" response to return <del> its resource identifier to the client.  The client can then retrieve protected resource metadata using the resource identifier as described in PRConfig.  The client might then, for instance, determine what authorization server to use for the resource based on protected resource metadata retrieved. </del> <ins> a URL to its protected resource metadata to the client.  The client can then retrieve protected resource metadata as described in PRConfig.  The client might then, for instance, determine what authorization server to use for the resource based on protected resource metadata retrieved. </ins> A typical end-to-end flow doing so is as follows.  Note that while this example uses the OAuth 2.0 Authorization Code flow, a similar

Related discussion:
text: Should the header return the full path to the Resource Metadata document, or return the resource identifier? RS Metadata document: the client fetches the exact URL returned Resource Identifier: the client builds the metadata URL by appending .well-known... and then fetches the URL What are the implications of this for resources that differ by path? (see mailing list thread about path-based resources that require different scopes)
I'm increasingly of the view that the resource identifier should be returned, which is what the draft already does. This aligns with the value in URL , which we normatively use. I propose that we say that during IETF 118 in Prague. If we get consensus on this, it will close our last remaining issue.
I'm wondering why the ended up the other route (advertising the URI of the resource metadata instead). Advertising the resource identifier in the would be more consistent with existing OAuth specifications as you pointed out. Advertising the resource identifier in the would make it possible for the client application to fetch an application-specific metadata documents () if it can handle it and the generic one () otherwise.
Code change:
This document also defines a format for SD-JWTs with Key Binding (SD- JWT+KB).  By optionally sending an SD-JWT+KB to a Verifier, the Holder can prove to the Verifier that they hold the private key <del> associated to the SD-JWT (e.g., using the </del> <ins> associated to the SD-JWT (i.e., using the </ins> claim RFC7800).  The strength of the binding is conditional upon the trust in the protection of the private key of the key pair an SD-JWT

Related discussion:
text: More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key
Code change:
would receive less bandwidth in case the bottleneck exists between the server and the intermediary. <del> 7.1.2. </del> <ins> 8.2. </ins> It is common for CDN infrastructure to support different HTTP versions on the front end and back end.  For instance, the client-

Related discussion:
text: and . I've left Security Consideration as TBD, I'll fill that out in a separate PR.
The text in about the client using priority to inform request scheduling is a good one, but it belongs elsewhere.
The whole discussion about fairness is worth having, but it doesn't really go to the usual security concerns. Security concerns might cover things like DoS through over-use of prioritization (see ), or use of priority to starve others (which might cross-reference the fairness text). But I think that the fairness text should be bumped up to the top level.
Code change:
Doing so makes them easier to identify programmatically (e.g., for stripping unrecognised hints from requests by privacy filters). <del> 5.2. </del> <ins> 4.3. </ins> A user agent that tracks access to active fingerprinting information SHOULD consider emission of Client Hints headers similarly to the way

Related discussion:
text: When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).
Code change:
The status code for a response. (content-status-code). <ins> A signature from a request message that resulted in this response message. (content-request-response) </ins> Additional specialty content identifiers MAY be defined and registered in the HTTP Signatures Specialty Content Identifier Registry. (content-registry)

Related discussion:
text: This creates a mechanism to cryptographically bind a response to its associated request by letting the responder sign the signature value of the request, and the requester validate the signature based on their original request's signature.
Code change:
http-only-flag is true, abort these steps and ignore the cookie entirely. <del> If the cookie's secure-only-flag is false, and the scheme component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: </del> <ins> If the cookie's secure-only-flag is false, and the request-uri does not denote a "secure" connection, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: </ins> Their name matches the name of the newly-created cookie.

Related discussion:
text: This PR removes the requirement of checking the request's redirect chain during the computation of same-site-ness. This is being done because RFC6265bis is blocked by this work but we have yet to find a way to implement it in a web compatible way. In the interest of moving RFC6265bis forward the requirement is being removed.
The work to re-add the requirement back into RFC6265tris is being track by issue
Yeah, we did implement this - but we had to back it out (and re-spin stable, IIRC?) because it broke too many sites. :(
Correct, Chrome had to disable the change. Firefox had a similar experience.
We noticed a difference between Firefox & Chrome’s behavior for same-site cookies. Specifically, if a web page is requesting a resource whose final redirect target is same-site with the web page, . Firefox follows what was originally decided in URL and specified in recent i.e., Firefox looks at the whole redirect chain. For context: Firefox shipped SameSite=Lax by default this January and had to backpedal due to this (and some other webcompat issues). Firefox does not ship SameSite=Lax as the default setting for new cookies as of now. While we’re still working on our own metrics, we’ve noticed that Chrome is seeing about 1% of page loads potentially affected, which seems prohibitively high. At the same time, we would prefer not to weaken our implementation of explicit SameSite cookies, given that the redirect check was specifically added to prevent CSRF abuse scenarios. With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie. NAME NAME it would be nice to hear some thoughts about this idea and also NAME how other browsers may have implemented . CC: NAME NAME NAME NAME NAME NAME
Yeah, I agree this is unfortunate. We did , but it broke a few sites and was backed out (or rather, put behind an off-by-default feature flag). NAME has been collecting better metrics so we can hopefully make progress on this. Can you give some more detail what you're thinking here? (also cc NAME


With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.
Code change:
http-only-flag is true, abort these steps and ignore the cookie entirely. <del> If the cookie's secure-only-flag is false, and the scheme component of request-uri does not denote a "secure" protocol, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: </del> <ins> If the cookie's secure-only-flag is false, and the request-uri does not denote a "secure" connection, then abort these steps and ignore the cookie entirely if the cookie store contains one or more cookies that meet all of the following criteria: </ins> Their name matches the name of the newly-created cookie.

Related discussion:
text: Firefox is already enforcing that all redirects are same-site for cookies that have an explicit or strict attribute. We would like to keep that restriction of course. From my understanding the idea would be that only cookies that don't define their own SameSite attribute and are then "lax-by-default" we would ignore the redirects.
As a side note, Chrome does send with these redirected sub-resource requests, so internally the networking code does seem to know the correct same-site value of the request. Obviously we'd like to do the more secure behavior all the time, but we are committed to doing the specified secure behavior for explicit SameSite cookies. Firefox has enforced this for explicit SameSite cookies for maybe around a year and has not suffered a noticeable amount of web incompatibility. We are in the (slow!) process of gathering telemetry to measure the impact of this on laxByDefault vs explictly SameSite cookies. Our hope is that we can convince Chrome folks to honor the spec for explicit SameSite cookies so that users and sites will be secure as promised by the spec, and that Firefox will be less likely to run into Web Compatibility problems in the future because of this. And that if we must weaken the behavior of laxByDefault (as it appears we must based on site breakage) that we explicitly change the spec to say "lax-ish by default" cookies follow Chrome's current behavior of ignoring redirects and comparing only the originator and the final request URL.
Hello and sorry for my late response. Our (Chrome's) metrics continue to show around 1% of page loads containing 1 or more cookies that would be blocked by this enforcement. While I'm unable to share numbers (yet, I'll add them to URL once they're approved) I can say that the vast majority of values triggering this are unspecified (lax by default). I wonder then if many of these cookies are likely those being accessed after a POST request from some login or payment flow redirect chain. I don't have any data to back this hunch up but URL hints this may be the case. If it is then perhaps we can tie the redirect chain enforcement to the 2 min Lax+POST mitigation. I.e.: Allow unspecified cookies to be accessible after cross-site redirects for up to 2 minutes.