jiebi/CodeConvo huggingface dataset:
Code change:
This type helps distinguish between responses generated by intermediaries from those generated by the origin. <del> 2.3.29. </del> <ins> 2.3.25. </ins> Name: http_request_denied

Related discussion:
text: However, having only a generic "catch-all" error with the real reason "hidden" in a free-form text in , that's going to vary from implementation to implementation, is going to make this less useful for any kind of automated processing and/or analysis. Ideally, I think, we should have specific enums that cover 95%+ of reasons happening in production, and only use the generic "catch-all" error for things not covered by them... So, playing the devil's advocate, perhaps we should add a few more? (Note that there is already raised on mismatched identity, SHA256, SPKI or other missed expectations.) Also, if you can get your hands on errors happening in production, that could help us make more informed decision here.
I agree we shouldn't do a 1:1 mapping (especially with a library), but the hierarchy needs to be clear, and mapped to terminology used in the standards. I.e., there should be a generic catch-all 'cert error' code, and then more specific ones for the major classes of problems.
TLS itself also contains a pile of certificate-verification-related alerts. Although I think the set is mostly just carried over from SSL. URL NAME may also have some thoughts on certificate verification error-reporting.
Despite what libraries may provide, for their developers, is fairly clear: the only defined result is a I think coupling any protocol-level expectation about diagnostics for errors is fundamentally misaligned. It should not matter, for example, whether a particular library checks the validity period of the certificate before the signature. We know, empirically, that different libraries do very different things there: macOS vs Mozilla NSS vs Microsoft CryptoAPI each verify something like validity at different points within their verification algorithms. We know it's deeply flawed to view there being "the" certificate chain for a server, because by definition, the chain is defined by the client's policy and set of trust anchors. As a consequence, we know that clients SHOULD implement certificate path building, to explore possible certificate chains, and we know that TLS 1.3 was explicitly updated to reflect those decades of running code and the emergent rough consensus that the message, beyond the first , is an attempt to aid/influence that. is a huge collection of different ways verifiers can process and examine errors, during forward path building and reverse verification, and notes that the trade-offs are heavily dependent upon client and use cases.
Code change:
This type helps distinguish between responses generated by intermediaries from those generated by the origin. <del> 2.3.29. </del> <ins> 2.3.25. </ins> Name: http_request_denied

Related discussion:
text: While I can understand the appeal for providing 'informational' statuses, any suggestion beyond a level of is probably too normative, and unsupported by the underlying specifications and best practices.
NAME the context here is a CDN or other reverse proxy reporting back errors in HTTP response headers, for debugging. There are no requirements around sending them (and senders are cautioned against leaking information that could aid an attacker). So, at one end a Boolean doesn't really help, and at the other end, the full list of errors by any one library (or all of them) is impractical. The list of alerts from NAME seems promising, and I note that we already have , whose value can be any TLS Alert string. However, That's intended to convey alerts received (and perhaps we should communicate that more clearly). The desired semantics here are that the problem indicated by the alert is generated in the client itself, not received by it. That leads me to believe that there are two viable paths forward: Rearrange the errors so that they mirror the alerts above (leaving 's semantic as stated above); e.g., we'd have , , and so forth Reduce everything into two errors, and or similar. Both would carry the TLS Alert value as an additional payload item. I think the difference is mostly stylistic, so NAME and I can figure that out. The bigger question is whether this is the right set of errors to focus upon.
But I think this is missing an important detail: from the perspective of a client, the only stable output is the boolean. For example, OpenSSL's reporting of errors is symptomatic of deeper flaws within its certificate verification; fixing those errors necessarily means some existing errors can't effectively be reported. This is covered at some length in . Ultimately, the set of errors that are relevant are, to an extent, subject to local policy: it's rare for certificate validators to think of errors in the ontology laid out by the TLS layer. Typically, a client just does a "best guess" (or just maps straight to ) when trying to map to the TLS layer, in part so it doesn't disclose extra information. This is certainly true when you think about local policy, such as limits on validity or the requirement of associated metadata, potentially delivered over TLS, such as Certificate Transparency or OCSP Must-Staple.
Code change:
This type helps distinguish between responses generated by intermediaries from those generated by the origin. <del> 2.3.29. </del> <ins> 2.3.25. </ins> Name: http_request_denied

Related discussion:
text: I think the core question is whether you expect the client and the proxy to be in the same management domain. If they aren't, and the ED seems to be oriented around this scenario (where server and proxy are likely same administrative domain, but proxy and client aren't), then it seems better served as an opaque diagnostic string. As RFC 4158 calls out, beyond the 'boolean' is really just an administrative/diagnostic capability, not something meant to be semantically rich, meaningful, or stable, and certainly not to allow next-hop policy decision making.
Just to be clear - the user agent isn't involved in this at all, beyond receiving the header so as to make it available to someone diagnosing a problem (Likely someone from the origin, from the CDN/reverse proxy operator, and/or a help desk talking to an end user). What I think I hear you saying is that we should define a generic error and allow implementations to convey textual detail in it. Does that make sense? I also still see some value in distinguishing a TLS alert received from the origin by the proxy (in its role as TLS client) from this case (a problem it encounters as a TLS client).
Yes. This matches with Criterion 2 of URL and the dual mode trade-off in URL , which perhaps more clearly highlights the local policy aspect ("Ultimately, the developer determines how to handle the trade-off between efficiency and provision of information"). 100% agreed here. I was only commenting to the extent at which the proxy validates the peer certificate independent of the TLS layer framing. Perhaps poorly stated, but my comment in URL was trying to capture that Option 2 from URL () would likely just reduce to a boolean anyways, in a well-behaved TLS client.
Code change:
dictionary available to use for compression. The "Available-Dictionary" request header is a lowercase <del> Base16-encoded RFC4648 hash of the contents of a single available dictionary calculated using one of the algorithms advertised as being supported by the server. </del> <ins> Base16-encoded RFC4648 SHA-256 hash of the contents of a single available dictionary. </ins> Its syntax is defined by the following ABNF:

Related discussion:
text: This removes the hashes negotiation and changes the Available-Dictionary request header to explicitly use sha-256 as discussed in URL If sha-256 becomes insufficient, the hash negotiation can then be added (or different mechanisms can be used). This is a rebased version of the (sorry, it got messy so it was cleaner to resubmit a clean one).
Code change:
sent in early data - thereby giving the client control over risk of replay.  Absent other information, clients MAY send requests with safe HTTP methods (see RFC7231, Section 4.2.1) in early data when it <del> is available, and SHOULD NOT send unsafe methods (or methods whose </del> <ins> is available, and MUST NOT send unsafe methods (or methods whose </ins> safety is not known) in early data. If the server rejects early data at the TLS layer, a client MUST

Related discussion:
text: NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!
Code change:
The term "public suffix" is defined in a note in Section 5.3 of RFC6265 as "a domain that is controlled by a public registry", and are also known as "effective top-level domains" (eTLDs).  For <del> example, "site.example"'s public suffix is "com".  User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. </del> <ins> example, "site.example"'s public suffix is "example".  User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. </ins> An origin's "registered domain" is the origin's host's public suffix plus the label to its left.  That is, for "https://www.site.example",

Related discussion:
text: URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME
Code change:
request and response. The resource is specified by the effective request URI and any <del> "validator" contained in the message. </del> <ins> "validator field" contained in the message. </ins> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not-

Related discussion:
text: "validator" refers to validator fields used in preconditions. The term validator fields seems more faithful to the original cache-validators in RFC3230. URL and URL
Code change:
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. <del> 2.4.1. </del> <ins> 2.6.1. </ins> The following table contains non-normative example HTTP messages and <del> their canonicalized "(request-target)" values. </del> <ins> their canonicalized "*request-target" values. </ins> 3.

Related discussion:
text: Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
Code change:
2. A Targeted Cache-Control Header Field (hereafter, "targeted field") <del> is a HTTP response header field that has the same syntax and semantics as the Cache-Control response header field I-D.ietf- httpbis-cache, Section 5.2.  However, it has a distinct field name that indicates the target for its directives. </del> <ins> is a HTTP response header field that has the same semantics as the Cache-Control response header field (HTTP-CACHING, Section 5.2). However, it has a distinct field name that indicates the target for its directives. </ins> For example:

Related discussion:
text: This strengthens the language around Structured Fields so that it's clear they're preferred, and targeted fields are now primarily defined as structured fields. It still leaves using a Cache-Control parser as an option. If we want to go further, we could remove the paragraph starting with 'However,...' and the two bullet points below that.
Reverted in URL for the record
Right now, parsing of targeted Cache-Control is specified like this: The idea here is that while we'd like the interop benefits of SF, we recognise that some -- perhaps many -- implementers will have a strong motivation to reuse their Cache-Control parsers. This seems like it might be the worst of both worlds, in that we now have two possible implementation strategies. Given that there are several now, I wonder whether should reconsider this. E.g., 1) Strengthen the first MAY to a SHOULD, making the field sf-first, or even 2) Require SF, don't allow reuse of CC parsers
Reopening to double-check that we still want to allow CC parsers.
To be clear: the remaining issue (as discussed at the interim) is whether we want to remove the text allowing parsers to be reused for this field.
This seems like the right balance: this is a profile of SF that a CC parser will accept, assuming that a CC parser won't choke on parameterization of "no-cache" or similar.
Code change:
11.5. <del> This section registers the </del> <ins> This section marks the </ins> <del> header field in the "Permanent Message Header Field Names" registry BCP90. </del> <ins> header field registered in RFC7540 as obsoleted. </ins> 11.6.

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
Abstract <del> This specification describes three CBOR data structures for primary use in COSE envelopes.  A CBOR encoding of Merkle Roots for use in COSE payloads.  A CBOR encoding of Inclusions Proofs for use in COSE unprotected headers.  A CBOR encoding of Consistency Proofs for use in COSE unprotected headers. </del> <ins> This specification describes verifiable data structures and associated proof types for use with COSE.  The extensibility of the approach is demonstrated by providing CBOR encodings for RFC9162. </ins> 1. <del> Merkle trees are verifiable data structures that support secure data storage, through their ability to protect the integrity of batches of documents or collections of statements. A merkle proof is a path from a leaf to a root in a merkle tree. Merkle proofs can be used to prove a document is in a database (proof of inclusion), or that a smaller set of statements are contained in a large set of statements (selective disclosure proofs). Typically, merkle trees are constructed from simple operations such as concatenation and digest via a cryptographic hash function. The simple design and valuable cryptographic properties of merkle trees have been leveraged in many network and database applications. Differences in the representation of a merkle tree, merkle leaf and merkle inclusion proof can increase the burden for implementers, and create interoperability challenges. This document describes the three data structures necessary to use merkle proofs with COSE envelopes. </del> <ins> Merkle trees are one of many verifiable data structures that enable tamper evident secure information storage, through their ability to protect the integrity of batches of documents or collections of statements. Merkle trees can be constructed from simple operations such as concatenation and digest via a cryptographic hash function, however, more advanced constructions enable proofs of different properties of the underlying verifiable data structure. Verifiable data structure proofs can be used to prove a document is in a database (proof of inclusion), that a database is append only (proof of consistency), that a smaller set of statements are contained in a large set of statements (proof of disclosure, a special case of proof of inclusion), or proof that certain data is not yet present in a database (proofs of non inclusion). Differences in the representation of verifiable data structures, and verifiable data structure proof types, can increase the burden for implementers, and create interoperability challenges for transparency services. This document describes how to convey verifiable data structures, and associated proof types in COSE envelopes. </ins> 1.1.

Related discussion:
text: This PR aligns the abstract and intro with generalizing away from specific merkle trees
LGTM
Code change:
response would contain the same representation that is enclosed as payload in this message. <ins> The field value is either an or a . In the latter case (uri), the referenced URI is relative to the target URI (RFC3986). </ins> The Content-Location value is not a replacement for the target URI (target.resource).  It is representation metadata.  It has the same syntax and semantics as the header field of the same name defined for

Related discussion:
text: Text taken from existing statement in Location.
Ah, makes sense, of course. Thanks NAME
NAME - can you check again?
2616's definition of said: 7231 dropped that, thanks to . We should probably restore it, given it can cause misconceptions like .
NAME do you remember why you removed that text?
Yes, the requirement moved into the general section on all URI-references. That is not a special case. And, no, its presence or absence would have made no difference to the referenced bug report. If either one of them had correctly followed the spec, they would have been fine. Instead, npm sent a special value without a special scheme, and Cloudflare marked that for rate limiting based on incorrect assumptions of bad behavior rather than the actual specification. Excuses happen.
NAME - I wasn't talking about the actual bug; I was talking about NAME -- someone who has implemented a very good HTTP engine -- misinterpreting the spec in that comment because it was reader-unfriendly. That should concern us all, because if he and implementers like him misread the spec so easily, it will be mis-implemented. And, the fault here is definitely not with him; it's with the spec. It's not reasonable to expect people to hold the entire specification series in their heads as they interpret each phrase and requirement, especially considering that in most renderings it's not cross-referenced (and even where the renderings support it, we don't cross-reference consistently). I understand that we need to be terse sometimes, and that it's reasonable to have expectations of our readers. But, when we use arcane terms and overload widely-used terms (even if incorrectly) to the point where the only people who understand the spec on a good day are you, Julian and I (and on a bad day, just you), it doesn't do anyone any good.
I think there are two ways to resolve this: 1) Link back to the URI section in each case where it's used, and adjust language to make it clear that there are requirements there 2) Add language in each case where a URI is a protocol element, and state how it's resolved I think I prefer (2), because is vague about how it specifies this: Since Section 2 is about HTTP URIs in general -- not just as protocol elements -- it's not clear what the scope of this statement is.
Code change:
response would contain the same representation that is enclosed as payload in this message. <ins> The field value is either an or a . In the latter case (uri), the referenced URI is relative to the target URI (RFC3986). </ins> The Content-Location value is not a replacement for the target URI (target.resource).  It is representation metadata.  It has the same syntax and semantics as the header field of the same name defined for

Related discussion:
text: It's also not a requirement, which doesn't seem good for interoperability.
Waiting for to land.
Places this will affect: Location Content-Location Referer
I still don't see any reason for this change. The spec already states how to do relative resolution in general, which it must do because it applies to all header fields (not just the ones we define). Saying it again on every occurrence of a relative or partial URI is just adding length to the spec.
We already said it for Location, and the amount of added text is minimal.
... and it's also said explicitly in . It may be obvious to you, but it's pretty clearly not to many implementers.
The only confusion has been our change in 7231 of the Location field to allow relative references. I am not aware of anyone ever being confused about the target URI being the base URI for all header fields, but I can live with more text if it says that consistently. To reiterate, this entire issue is based on a misreading of a completely mistaken assumption about the field content of "Referer: install" being flagged as a potential security issue by Cloudflare because it is unusual, not because Cloudflare somehow might not have been aware that the syntax is allowed by the spec as a relative reference. It's defense by spec-lawyering. These changes would not have changed Cloudflare's algorithm and would not have convinced npm to choose a more common default. Actually talking to their own CDN before deploying an HTTP change would have helped. Testing would have prevented it entirely.
NAME is right that the prose needs to be in sync with the actual ABNF. Will update the PR later today with a proposal.