jiebi/CodeConvo huggingface dataset:
Code change:
ABNF rule in HTTP. <ins> An intermediary that receives any field that requires removal before forwarding (see HTTP) MUST remove or replace those header fields when forwarding messages.  Additionally, intermediaries should take care when forwarding messages containing Content-Length fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </ins> 10.4. Pushed responses do not have an explicit request from the client; the

Related discussion:
text: Here is some draft text. In principle we don't need any of this at all: as this text shows, all of the relevant guidance is already present in both semantics and H2. I've elected to throw up some possible text, but if we wanted to say that some or all of it is entirely redundant with existing specifications then I'm happy to do so.
Upgrade, Transfer-Encoding, Content-Length, Connection, and anything listed in Connection MUST NOT be forwarded without modification. See also .
Note that this probably goes in
I have no personal knowledge of this issue, but it came up on the #whatwg IRC channel. URL describes Safari rejecting responses that contain the header field, while other browsers accept it. It'd be good to converge the major clients on a single behavior and, if that's not the behavior currently specified, update the spec to match.
To be clear, that's nginx being spectacularly broken by forwarding the header field. I'd characterise the philosophy of H2 as being strict with errors that endanger the whole connection -- and counts the server asking for an upgrade in a context where it doesn't make sense as qualifying as such. While I'd be surprised if folks wanted to relax the former (the strictness is a net win for H2), the latter might be worth revisiting, not because nginx is broken, but because H1's use of headers for connection-level mechanisms turned out to be so broken. I'm also not sure that aligning all clients to be so permissive is such a great idea; accommodating brokenness like this is a race to the bottom, and while it might be the only practical path when you have to interoperate with a large and extremely diverse pool of existing deployment (HTML), there aren't that many HTTP implementations that can move the needle. Interop might be better served by holding the line and forcing broken servers to address their problems.
Additionally, it seems broken for Apache to send the header when the connection between nginx and Apache is over TLS.
Filed .
Apache treats the effects of sending over TLS as a UA-side bug. :-(
Yeah, this looks bad. The spec is fairly unambiguous about the requirement to ignore Upgrade in one place. But it also prohibits the use of Connection, which implies that you can't use Upgrade. I think that we should fix this, potentially along with . I hope that we are able to convince NAME to change Apache here. There is no value in sending this value.
FYI analysis,
Code change:
4. <del> TODO: register the "Client-Cert" HTTP header field in the registry defined by http-core. </del> <ins> The "Client-Cert" HTTP header field will be added to the registry defined by http-core. </ins> 5.  References

Related discussion:
text: I've opened issues for the things that were previously TODO comments in the draft; this removes them from the draft itself.
Issues and for posterity
NAME wrote: Public Keys is maybe worth considering. This too is this is an area for further discussion and consideration should this draft progress.
My take: keep the scope of this narrow. If raw keys are needed - or other certificate types for that matter - then we can define another field.
I concur with Martin's take. The TODO made its way into the individual draft (and subsequently became this issue) based largely on this brief suggestion in one part of an off-list email on the topic, "While I do not know of a use case yet, it might be worth keeping raw public keys in mind as a use case." Which is not unreasonable but I'm going to favor narrow scope here over speculative need.
NAME wrote: might be needed/wanted by the backend application (to independently evaluate the cert chain, for example, although that seems like it would be terribly inefficient) and that any intermediates as well as the root should also be somehow conveyed, which is an area for further discussion should this draft progress. One potential approach suggested by a few folks is to allow some configurability in what is sent along with maybe a prefix token to indicate what's being sent - something like Client-Cert: FULL \ \ \Client-Cert: EE \ as the strawman. Or a perhaps a parameter or other construct of {{?RFC8941}} to indicate what's being sent. It's also been suggested that the end-entity certificate by itself might sometimes be too big (esp. e.g., with some post-quantum signature schemes). Hard to account for it both being too much data and not enough data at the same time. But potentially opening up configuration options to send only specific attribute(s) from the client certificate is a possibility for that. In the author's humble opinion the end-entity certificate by itself strikes a good balance for the vast majority of needs and avoids optionality. But, again, this is an area for further discussion should this draft progress.
I would propose a separate header for the chain that would use the structure List value format.
I'd also argue strongly for enabling the certificate chain (even if as a list of sha256 checksums of entities in the chain).
Code change:
4. <del> TODO: register the "Client-Cert" HTTP header field in the registry defined by http-core. </del> <ins> The "Client-Cert" HTTP header field will be added to the registry defined by http-core. </ins> 5.  References

Related discussion:
text: End-entity certificates are effectively namespaced by the rest of the chain, so not including the full chain and/or not tying the end-entity cert to the chain are some of the top foot-guns I've found with people using this.
I like NAME suggestion: separating the EE certificate out is sensible. The assumption here is that the terminating proxy validates the signature from the EE cert when establishing the connection. That makes it different. That said, the origin server might need to assemble and validate the chain, so including all the data presented in TLS is likely necessary. (I don't think hashes are as generically useful; space savings can be achieved with header compression, assuming that you use VERY large tables.)
From a header compression standpoint, I suspect we should note that multiple instances of the header will compress more efficiently than a single instance with a long list, assuming there are multiple possible intermediate cert paths.
NAME wrote: http-core. This should be pretty simple to add, but for the purposes of having a clean PR pulling out the TODOs, I'm moving it to an issue for now anyway.
URL points to draft-ietf-httpbis-semantics for this
NAME wrote: possible with HTTP1.1 and maybe needs to be discussed explicitly here or somewhere in this document? Naively I'd say that the header will be sent with the data of the most recent client cert anytime after renegotiation or post-handshake auth. And only for requests that are fully covered by the cert but that in practice making the determination of where exactly in the application data the cert messages arrived is hard to impossible so it'll be a best effort kind of thing.
Code change:
The claim value object MUST contain a "typ" (type) attribute with a string based value that represents the type of status list referenced.  The value MUST be equal to that of the "typ" <del> attribute in the "status" claim for the token who's status is being validated. </del> <ins> attribute in the "status" claim for the Referenced Token who's status is being validated. </ins> The claim value object MUST contain a "lst" (list) attribute with a string based value that represents the status values for all the <del> tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </del> <ins> Referenced Tokens it conveys statuses for.  The value MUST be a base64 encoded string using RFCXXX containing a GZIP compressed octet string RFC1952. </ins> <del> 3.3. </del> <ins> 4.3. </ins> This document formally defines the "revocation-list" status list type which applies the following additional validation rules beyond those <del> described in jwt-format-and-processing and jwt-status-list-format- and-processing. </del> <ins> described in jwt-referenced-token and jwt-status-list-format-and- processing. </ins> The "uri" attribute contained within a JWT using the "status" claim MUST be an HTTPS based URL that when resolved via an HTTPS GET

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
Code change:
contains the end-entity certificate used by the client in the TLS handshake. <del> Client-Cert is an Item Structured Header RFC8941.  Its value MUST be a Byte Sequence (RFC8941).  Its ABNF is: The value of the header is encoded as described in encoding. </del> <ins> Client-Cert is a Byte Sequence with the value of the header encoded as described in encoding. </ins> The "Client-Cert" header field is only for use in HTTP requests and MUST NOT be used in HTTP responses.  It is a singleton header field

Related discussion:
text: try to align better with the style guide on structured fields usage for
See URL, which would affect sections 2.2 and 2.3
Will update the structured fields parts to align with the style guide.
LGTM
Code change:
A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the

Related discussion:
text: NAME PTAL.
Client/Server Messaging still is HTTP/1.1-specific. Suggested deletions below: Also, trailers?
Textual reason-phrase is also 1.1 specific.
NAME what's the implication of that? It's already suggested to be deleted.
It wasn't in a previous iteration of your suggestion -- see your edit history. Perhaps we noticed this in parallel?
Ah ;)
Somewhat related is .
This text seems out of place in 3.2 Storing Responses to Authenticated Requests. It also omits .
It seems like it's covered by 4.2.4 pretty completely.
Code change:
A client sends an HTTP request to a server in the form of a <del> message, beginning with a request-line that includes a method, URI, and protocol version (request.line), followed by header fields containing request modifiers, client information, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> message, beginning with a method (methods) and URI, followed by header fields containing request modifiers, client information, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). </ins> A server responds to a client's request by sending one or more HTTP <del> messages, each beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase (status.line), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, message.body). </del> <ins> messages, each beginning with a success or error code (status.codes), possibly followed by header fields containing server information, resource metadata, and representation metadata (header.fields), and finally a message body containing the payload body (if any, message.body). A connection might be used for multiple request/response exchanges. </ins> The mechanism used to correlate between request and response messages is version dependent; some versions of HTTP use implicit ordering of messages, while others use an explicit identifier. <del> A connection might be used for multiple request/response exchanges, as defined in persistent.connections. </del> Responses (both final and non-final) can be sent at any time after a request is received, even if it is not yet complete.  However, clients (including intermediaries) might abandon a request if the

Related discussion:
text: Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.
Code change:
Status List values.  The registry records the a human readable label, the bit representation and a common description for it. <ins> Status Types are registered by Specification Required [RFC5226] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of names prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register Status Type name: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. </ins> 14.5.1. Status Type Name:

Related discussion:
text: We would register: CWT Status Mechanisms registry in CWT JWT Status Mechanisms registry in JWT Status Types registry in OAuth parameters Any ideas how we could simplify this?
looks good to me in general. I would extend this to more than two weeks, if I look back how the current year went by. I think this is a good start for now, so we should merge this first and then evaluate afterwards if we can merge both status registries.
JWT/CWT registries use three week periods, the OAuth Parameter one uses two weeks. Should we just align with these registries for each one?
Section 4 of RFC 8126 -> supply registration procedures for the registries Define where these registries should be placed
Editors Call: we propose to put into OAuth Parameters: URL
Code change:
seconds (see delta-seconds). Although it is defined as a singleton header field, a cache <del> encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. </del> <ins> encountering a message with a list-based Age field value SHOULD use the first member of the field value, discarding subsequent ones. </ins> <del> If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </del> <ins> If the field value (after discarding additional members, as per above) is invalid (e.g., it contains something other than a non- negative integer), a cache SHOULD ignore the field. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Related discussion:
text: Apologies for the lateness, but going through , I think we need to adjust handling of invalid headers: Right now, it's that caches SHOULD treat responses with invalid values as stale. However: No cache tested treats a response with in this manner; all ignore the field. Only Fastly and Firefox treat a response with in this manner; the rest ignore the field. Interestingly, most caches do consider a response with to be stale, except for Apache and Chrome. We specify that the first field line should be used when multiple are present. That's almost universally adhered to (with one deviation by Safari), but we omit multiple values on the same field line from this rule (which are treated as invalids as per above). However: When that line is , all caches reuse the response. When that line is , only Safari and Apache reuse it. This suggests that we could align with current implementations and improve interoperability by: Specifying that invalid fields should be ignored, not make the response stale. This is nearly universal practice. Specifying that the first field value should be used when multiple can be parsed. This is also nearly universal practice.
Code change:
confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail.  This might be particularly helpful when the destination host is not responding, as <del> TCP handshakes can hang for several minutes before failing. Implementation of "100 (Continue)" support is OPTIONAL for clients and REQUIRED for proxies. </del> <ins> TCP handshakes can hang for several minutes before failing.  Clients MAY send "Expect: 100-continue", and proxies MUST respect it by returning "100 (Continue)" if the request is not immediately rejected. </ins> Proxies implementing this specification SHOULD include a "Proxy- Status" response header RFC9209 in any success or failure response

Related discussion:
text: The draft says "Implementation of "100 (Continue)" support is OPTIONAL for clients and REQUIRED for proxies." What does that mean? Is the client allowed to fall over if it receives 100? (This is not a theoretical concern, many HTTP libraries stop listening for header blocks after the first one.)
I've posted to reduce ambiguity here. RFC 9110 I think that makes it pretty clear that clients are supposed to tolerate unexpected 100s.
Code change:
that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del> <ins> 5.2.2. The Txn-Token SHOULD contain an "azd" claim.  The value of this claim is a JSON object that contains name/value pairs (wherein the value could itself be an object), which together assert the details that remain immutable through the call-chain where this Txn-Token is used. Txn-Tokens are primarily used to assure identity and context for a transaction, and the content of this field is a critical part of that context. Whereas the "rctx" field contains environmental values related to the request, the "azd" field contains the actual authorizaiton details that are determined by the TTS.  These values are used by services using the Txn-Token to reliably obtain specific parameters needed to perform their work.  The content of the "azd" field is determined by the Txn-Token Service and they may be computed internally or from parameters it receives from the service that requests the Txn-Token. The following is a non-normative example of an "azd" claim: 5.2.2.1. </ins> It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this

Related discussion:
text: To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good