jiebi/CodeConvo huggingface dataset:
Code change:
attacks.  Implementers should use care in determining what to disclose in the challenge and in what circumstances.  The logic examining the incoming access token to determine whether a challenge <del> should be returned can execute either before or after the traditional token validation logic, be it based on JWT token validation, introspection, or any other method.  The resource server MAY return a challenge without verifying the client presented a valid token. However, this approach will leak the required properties of an authorization token to an actor who has not proven they can obtain a token for this resource server. </del> <ins> should be returned can execute either before or after the conventional token validation logic, be it based on JWT token validation, introspection, or any other method.  The resource server MAY return a challenge without verifying the client presented a valid token.  However, this approach will leak the required properties of an authorization token to an actor who has not proven they can obtain a token for this resource server. </ins> As this specification provides a mechanism for the resource server to trigger user interaction, it's important for the authorization server

Related discussion:
text: updates from Lars Eggert's IESG review/ballot URL Lars Eggert has entered the following ballot position for draft-ietf-oauth-step-up-authn-challenge-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: CC NAME Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (URL). Found terminology that should be reviewed for inclusivity; see URL for background and more guidance: Term ; alternatives might be , , , , , , , , , , , , , , , , All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. These URLs in the document can probably be converted to HTTPS: URL This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. Consider using "after". The verb form "needs" does not seem to match the subject "servers". An apostrophe may be missing. This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [ tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [][IRT]. [ICMF]: URL [ICT]: URL [IRT]: URL
Code change:
8.8. <del> Validator fields convey metadata about the </del> <ins> Resource metadata is referred to as a if it can be used within a precondition (preconditions) to make a conditional request (conditional.requests).  Validator fields convey a current validator for the (representations). </ins> <del> (representations).  In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response.  Note that, depending on the status code </del> <ins> In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response.  Note that, depending on the method and status code </ins> semantics, the for a given response is not necessarily the same as the

Related discussion:
text: … (now entirely handled by HTTP/1.1 messaging). Include LF in discussion of what characters are invalid in field values. Require obs-fold to be processed when consuming message/http data.
Citing Ben Kaduk (URL): (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. In RFC723x, field-value allowed obs-fold. We need to: tune the prose above, and somehow properly allow it in message/http (maybe by modifying the field-value for that specific case???)
see also URL
This is a good change. A few things that might be worth considering, when comparing this to recent HTTP/2 changes. HTTP/2 prohibits additional things in field names: SP (0x20), COLON (0x3a), 0x01-0x1f, and 0x7f-0xff (inclusive), specifically. The other things in h2 are specific to that. That includes leading and trailing space in values (you just say "A field value does not include leading or trailing whitespace") and uppercase field characters are version-specific.
Code change:
CertificateVerify and Finished messages. HTTP/2 restricts TLS 1.2 renegotiation (RFC9113) and prohibits TLS <del> 1.3 post-handshake authentication RFC8740.  However, they are </del> <ins> 1.3 post-handshake authentication (RFC9113).  However, they are </ins> sometimes used to implement reactive client certificate authentication in HTTP/1.1 RFC9112 where the server decides whether to request a client certificate based on the HTTP request.  HTTP

Related discussion:
text: correcting: The reference to RFC8740 is obsoleted by RFC9113 There are two separate references to RFC5246, once as "RFC5246" and once as "TLS1.2".
Code change:
with an appropriate link. After that is complete, please update the new registry with the field <del> names listed in the table of field.names. </del> <ins> names listed in the table of field.definitions. </ins> Finally, please update the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to RFC2616 (for the

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:
with an appropriate link. After that is complete, please update the new registry with the field <del> names listed in the table of field.names. </del> <ins> names listed in the table of field.definitions. </ins> Finally, please update the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to RFC2616 (for the

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.
Code change:
against one another for consistency when these lists are used by the application profile. <del> 7.5. </del> <ins> 7.6. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server

Related discussion:
text: "The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."
Code change:
requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and <del> a half BDP.  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </del> <ins> a half times the Bandwidth Delay Product (BDP).  This was unsatisfactory, and indeed further versions have fixed this aspect of BBR BBR-draft. </ins> This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track

Related discussion:
text: All I did in that sentence is expand BDP. If you would like to change its content, please file a different PR.
Thanks Sean Turner: Questions: s3.2: This section includes the following: This document applies to proposals for congestion control algorithms that seek Experimental or Standards Track status. So ... if I get an Informational RFC I can do whatever I want? Wondering why Informational isn't listed here. s5.3.2: The 1st para invokes some like requirements language like "ought to" and "it would be helpful". Any reason there isn't BCP 1 4language used in this para? s6: Is "MUST find" another way of saying there must be coommunity consensus? If so maybe: OLD: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST find that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. NEW: Unless a proposed congestion control specification explicitly forbids use on the public Internet, the community MUST reach consensus that it meets the criteria in these scenarios for the proposed congestion control algorithm to progress. Nits: s5.1.3, 2nd para: expand BDP. s7.9, lastt para: s/(see Section 4./(see Section 4).
I think this could be read as endorsing the change to BBR - but that isn't the case, maybe: /fixed/addressed/ or something similar, to show the intent.
Code change:
MUST NOT fail the parsing to facilitate the addition of new limits in the future. <ins> A server that supports the creation of a resumable upload resource (upload-creation) under a target URI MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request sent to this target URI.  If a server supports the creation of upload resources for any target URI, it MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request with the "*" target.  The limits announced in an "OPTIONS" response SHOULD NOT be less restrictive than the limits applied to an upload once the upload resource has been created.  If the server does not apply any limits, it MUST use "min-size=0" instead of an empty header value.  A client can use an "OPTIONS" request to discover support for resumable uploads and potential limits before creating an upload resource. </ins> 8.3. The "Upload-Complete" request and response header field indicates

Related discussion:
text: Proposal for optimistic: The client needs to adapt to the header provided in the intermediate response and fail the request if the file is larger than the maximum allowed size. Proposal for Careful: The client can use the header provided in the to verify that the file is allowed to be uploaded before sending any data.Some editorial suggestions, but one big question: What is the material difference between the first and third strategy? Could these be the same strategy?
Code change:
MUST NOT fail the parsing to facilitate the addition of new limits in the future. <ins> A server that supports the creation of a resumable upload resource (upload-creation) under a target URI MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request sent to this target URI.  If a server supports the creation of upload resources for any target URI, it MUST include the "Upload-Limit" header field with the corresponding limits in a response to an "OPTIONS" request with the "*" target.  The limits announced in an "OPTIONS" response SHOULD NOT be less restrictive than the limits applied to an upload once the upload resource has been created.  If the server does not apply any limits, it MUST use "min-size=0" instead of an empty header value.  A client can use an "OPTIONS" request to discover support for resumable uploads and potential limits before creating an upload resource. </ins> 8.3. The "Upload-Complete" request and response header field indicates

Related discussion:
text: due to lack of support for 1xx responses) who whishes to know upfront if the upload can be split (Upload-Complete: ?0) or if a regular upload (without resumability) should be performed.
Interesting idea! The presence of the Upload-Limit header could be used as an indicator for support of resumable uploads. In theory, its value can be an empty dictionary as well if the server does not impose any limits. If the response does not include the Upload-Limit header, the client can either attempt an upgradable upload or directly fall back to regular uploads.
URL
Too bad we can't use the empty dictionary header as an indicator. It's probably an edge case anyway that a client, not knowing the support of the server, would issue an OPTIONS request to find out? Or maybe not, given CORS? What do others think?
Thanks for the pointer, Lucas! If we cannot use an empty value, a server could also fill in a dummy value, e.g. . This is only necessary if the server does not apply any limit at all (not even ), which I suppose is very rare in reality. In general, the situation where a client wants to know upfront whether the server supports resumable uploads appears like an edge case to me. I assume the client will often know that the server supports it or otherwise will attempt to transparently upgrade a traditional upload into a resumable one. So I don't think we have to spend too much energy on this. How do you feel about this, Stefan?
NAME Yeah I think that is fair enough. The use cases where a generic client (without prior knowledge of server support nor support for informational responses) would send an extra OPTIONS request seems slim to none. The CORS example is interesting but mostly (always?) happens in a browser which does support informational responses and thus would use the 104.
Opened URL for this.
Code change:
store arbitrary data in a cookie-value SHOULD encode that data, for example, using Base64 RFC4648. <del> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </del> Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters.  Note that in this case, the initial and trailing DQUOTE characters are not stripped.  They are part of the cookie-value, and will be included in Cookie header fields sent to the server. <ins> The domain-value is a subdomain as defined by RFC1034, Section 3.5, and as enhanced by RFC1123, Section 2.1.  Thus, domain-value is a string of USASCII characters, such as one obtained by applying the "ToASCII" operation defined in Section 4 of RFC3490. </ins> The portions of the set-cookie-string produced by the cookie-av term are known as attributes.  To maximize compatibility with user agents, servers SHOULD NOT produce two attributes with the same name in the same set-cookie-string.  (See storage-model for how user agents handle this case.) <ins> NOTE: The name of an attribute-value pair is not case sensitive.  So while they are presented here in CamelCase, such as "HttpOnly" or "SameSite", any case is accepted.  E.x.: "httponly", "Httponly", "hTTPoNLY", etc. </ins> Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.  (See set-cookie for how user agents handle this case.)

Related discussion:
text: The case where the value contains an '=' is interesting though, and not tested by WPTs I believe. The Set-Cookie header can't produce a nameless cookie with value so this is only a concern for non-HTTP APIs that don't parse a set-cookie-string. Could we instead just add to the Storage Model section the restriction that the cookie-name and cookie-value cannot contain '=' or ';' characters? (Side note, more generally, this is getting out of hand and we should try to factor out common logic in the Storage Model and set-cookie-string parsing sections.)
hmm, looks like there is a WPT for this case, but the expected output for it would be interpreted incorrectly :( URL;l=22-26 Wouldn't be allowed in a Set-Cookie header? Also, '=' is a valid base64 character, so not allowing it in might cause a lot of headaches
Oh, my mistake, you're right that creates a nameless cookie with value . Chrome/Edge/Firefox agree on how to serialize these, but Safari ignores nameless cookies altogether. I would be a bit concerned about breaking stuff if this serialization changed. :-/ Theoretically there's a use case for this behavior... since and are the same cookie (the nameless cookie) but with different values, and they overwrite each other, a site could be relying on getting the output or (but never both) as a way of (sort of) setting two mutually exclusive cookies named and .
Maybe we just fix this with a note cautioning against using nameless cookies, and point to this issue as a warning.
Code change:
HTTP uses <del> names to indicate or negotiate the character encoding scheme of a textual representation RFC6365.  A charset is identified by a case- insensitive token. </del> <ins> names to indicate or negotiate the character encoding scheme (RFC6365) of a textual representation.  In the fields defined by this document, charset names appear either in parameters ( ), or, for , in the form of a plain .  In both cases, charset names are matched case-insensitively. </ins> Charset names ought to be registered in the IANA "Character Sets" registry (<https://www.iana.org/assignments/character-sets>)

Related discussion:
text: is deprecated due to the ubiquity of UTF-8, but the section makes no mention of UTF-8. This might be worth a mention.
It's only used for though and that section already mentions UTF-8. As does the Media Type section. Since is deprecated, perhaps the production should simply be removed and takes directly?
Accept-Charset is deprecated primarily for privacy. It also happens to be less useful now because of utf-8. In contrast, the charset parameter is still used most of the time, mainly to reduce sniffing. We can add something about utf-8, but promoting it too hard will cause other (social) problems.
NAME observation is correct. But then, charset is used in Content-Type as well, just not referenced directly as it is used over there as a regular parameter.
It's not clear to me at least that the production section also applies to .
Syntactically, it does not (because that relies on a more generic syntax for arbitrary parameters). But I agree, this needs cleanup.
Proposal is to remove the ABNF production and to clarify the text (so that it applies to Content-Type as well).