jiebi/CodeConvo huggingface dataset:
Code change:
4.1. <del> IANA is asked to update the "HTTP Content Coding Registry" registry (HTTP) according to the table below: </del> <ins> IANA is asked to enter the following into the "HTTP Content Coding Registry" registry (HTTP): Name: br-d Description: A stream of bytes compressed using the Brotli protocol with an external dictionary of not more than 16 MB. Reference: This document Notes: IANA is asked to enter the following into the "HTTP Content Coding Registry" registry (HTTP): Name: zstd-d Description: A stream of bytes compressed using the Zstandard protocol with an external dictionary of not more than 8 MB. Reference: This document Notes: </ins> 4.2.

Related discussion:
text: Frankly, I'm also very open to also adding a flag (and equivalent compression parameter in the library) that would just look at the size of the dictionary (which zstd necessarily has access to) and would configure the window accordingly. In that case, users wouldn't have to do any math at all.
OK, I chaged the structure and language so that they are no longer streams of bytes compressed with a given algorithm but are now specifically and . The references for those named formats have the window restrictions (which for Zstandard includes the 1.25x dictionary requirement). Currently the byte stream itself is still a native Brotli/Zstandard stream, just with specific settings but this also makes it cleaner if we decide to . PR with the update is here: URL
lgtm other than the comment
Code change:
contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. <del> 15.5.21. </del> <ins> 15.5.22. </ins> The

Related discussion:
text: I haven't checked the errata yet, but I have to go now and this is worth reviewing.
Maybe end the last paragraph with: "Because of this default, senders in general should mark it as non-cacheable using ...".
sry, accidentally merged early; we still need to deal with the erratum
I don't understand what happened here, but master does not contain the changes that github thinks have been merged.
Yes, I tried to undo my mistake.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
A much belated approval from me. This looks good.
Code change:
contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions. <del> 15.5.21. </del> <ins> 15.5.22. </ins> The

Related discussion:
text: This is an attempted recovery of the prematurely merged pull request that left us in a bad state.
(we might want to link to the erratum in the change notes, let me know if I should do that)
NAME - are you ok with this one?
Yes. I indicated my support for the pull request.
I think we need to copy the 421 status code definition from since it is generally applicable for rejecting a misdirected request.
curious if NAME has an opinion on moving 421 to http-core
A slight preference for moving it, I think.
Since we're doing h2bis and since it is applicable more broadly, I agree.
When doing so, we need to consider URL
Hmm, the errata is about the cacheable paragraph (which is now heuristically) and I was going to remove that for the same reason but decided to import without changes first. I am just going to remove it now.
That might work as well; but then we'll have to mention in "changes" that the default changed.
Code change:
3.3.1. Proposed congestion control mechanisms SHOULD include a clear <del> explanation of the deviations from RFC2914. </del> <ins> explanation of the deviations from RFC2914 and RFC7141. </ins> 3.3.2.

Related discussion:
text: rfc7141 partially updates rfc5033; include relevant sections in the -bis document
7141 does not mention 5033, so can you be more specific?
Oct 12: Pinged NAME to follow up
IIRC, it was due to rfc7141 updating rfc2914; rfc2914 is mentioned and referenced at numerous points throughout the 5033 document. 5033bis should heed the advice from 7141 around marking probabiliy taking into consideration packet sizes rather than only the packets themselves. At least this train of thought is the most likely one, which was had in my mind at the time.
Editors: we suspect that this question is orthogonal to the purpose of this document; will look more carefully at the reference.
It turns out that 7141 does have recommendations on response to congestion signals from the network, not just AQM recommendations (See Sec 2.3 and 2.4 for a good summary).
Code change:
3.3.1. Proposed congestion control mechanisms SHOULD include a clear <del> explanation of the deviations from RFC2914. </del> <ins> explanation of the deviations from RFC2914 and RFC7141. </ins> 3.3.2.

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
offset of the incomplete upload by sending a "HEAD" request to the upload resource. <del> The request MUST NOT include the "Upload-Offset" header or the "Upload-Complete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Complete" header by sending a "400 (Bad Request)" response. </del> <ins> The request MUST NOT include an "Upload-Offset" or "Upload-Complete" header field.  The server MUST reject requests with either of these fields by responding with a "400 (Bad Request)" status code. </ins> If the server considers the upload resource to be active, it MUST <del> send back a "204 (No Content)" response.  The response MUST include the "Upload-Offset" header set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header which is set to true if and only if the upload is complete. </del> <ins> respond with a "204 (No Content)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </ins> An upload is considered complete only if the server completely and <del> successfully received a corresponding creation (upload-creation) request or append (upload-appending) request with the "Upload- Complete" header being set to true. </del> <ins> successfully received a corresponding creation request (upload- creation) or append request (upload-appending) with the "Upload- Complete" header value set to true. </ins> The client MUST NOT perform offset retrieval while creation (upload- creation) or append (upload-appending) is in progress.

Related discussion:
text: See URL Lots of boring editorial tweaks to ensure better consistency both within the document and other HTTP specs.
One related question: The style guide also mentions that "examples should be in HTTP/1.1 format unless they are specific to another version of the protocol", but the draft uses a notation that resembles HTTP/2. Should we change the example messages to HTTP/1.1?
Thank you very for this tedious work! I only spotted a few minor typos.
Code change:
PROTOCOL_ERROR; errors on the connection flow-control window MUST be treated as a ConnectionErrorHandler. <del> WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag.  This means that a receiver could receive a </del> <ins> WINDOW_UPDATE can be sent by a peer that has sent a frame with the END_STREAM flag set.  This means that a receiver could receive a </ins> WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an error (see StreamStates).

Related discussion:
text: Going to let NAME have a look at this as well.
(Warning, I may have reached peak pedantry.) In Section 5.1, there are two references to frames which "contain" an ENDSTREAM flag. All HEADERS, CONTINUATION, and DATA frames contain this flag, which might be set or not. Most other references in the document are to the flag being set, which is more precise. There are also two references to frames "bearing" ENDSTREAM, which could be taken either way.
If you care enough to write the issue, maybe you also care enough to offer a pull request.
Code change:
because it is not clear whether they will be used, and sending them impacts both performance and privacy. <del> This document defines two response headers, Accept-CH and Accept-CH- Lifetime, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." </del> <ins> This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." </ins> Note to Readers

Related discussion:
text: Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM
Code change:
9.2. <ins> Requests without a payload body can still send a Digest field applying the digest algorithm to an empty representation. </ins> As there is no content coding applied, the "sha-256" and the "id-sha- <del> 256" digest-values are the same. </del> <ins> 256" digest-values in the response are the same. </ins> Request:

Related discussion:
text: adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256
Code change:
6.8. <del> The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this connection.  GOAWAY can be sent by either the client or the server.  Once sent, the sender will ignore frames sent on any new streams with identifiers higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams.  This enables administrative actions, like server maintenance. </del> <ins> The GOAWAY frame (type=0x7) is used to initiate shutdown of a connection or to signal serious error conditions.  GOAWAY allows an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams.  This enables administrative actions, like server maintenance. </ins> There is an inherent race condition between an endpoint starting new streams and the remote sending a GOAWAY frame.  To deal with this

Related discussion:
text: The intent was to say that the receiver of a GOAWAY can't create new streams higher than the value in GOAWAY. Let me check back in tomorrow; maybe fresh eyes will add perspective.
So the intention of the change is allow receiver of GOAWAY are still allowed to create stream lower or equal to received last-stream-id, accepting the fact that those streams are ignored by peer? As the graceful shutdown process as described in draft 17, server first sending GOAWAY with (2^31) - 1 starts to ignore any new streams created by peer and after some time (this ensures that GOAWAY is reached to the client), server sends another GOAWAY with updated last-stream-id where processing has occurred already.
NAME the intent of the change is to not change anything :) The process has been unclear, but the point is that if you receive GOAWAY with a last-stream-id greater than anything you have initiated, you can use what space remains for new streams. What that means is that you can issue new requests on that connection while you take the time to create a replacement connection. This was considered critical for . That means that 2^31-1 serves only as a warning of impending closure, though in theory it need not change any behaviour for the existing connection. I'd take steps to make a replacement connection though.
Thank you for clarification!
Here is a link to NAME doc from the mailing list which provides additional clarity to this issue URL
Latest PR is much more comfortable to me. Thanks!
Code change:
Consume the first character of input_string; if it is not "=", fail parsing. <del> If the first character of input_string is "(", let this_value be the result of running Parsing an Inner List (parse- innerlist) with input_string. Else, let this_value be the result of running Parsing an Item (parse-item) with input_string. </del> <ins> Let member be the result of running Parsing a Parameterized Member from Text (parse-param) with input_string. </ins> <del> Add name this_key with value this_value to dictionary. </del> <ins> Add name this_key with value member to dictionary. </ins> Discard any leading OWS from input_string.

Related discussion:
text: Now that we are generalizing how the types are used, I think it might be a good idea to allow a dictionary value to be a mapping (i.e., a list of parameters). This would be a generalization. At the moment, top level elements can contain scalars, lists, or dictionaries. However, it is at the moment impossible to use a dictionary at the second level even though scalars and lists are permitted. In terms of use-case, the proposed change would allow for example something like a cache-control directive to take a mapping as an argument (see URL). Logic-wise, I assume that the added complexity would not be significant, as we can reuse the definition for the parameters of a parameterised list.
NAME are you just asking for parameters on dictionary values, in a manner that's equivalent to list values?
NAME Sorry for the belated response. Yes. I'd be fine with member-value being exactly list-member.
Code change:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> While Section 5.4 of RFC9110 does not define a length limit for header fields it is likely that the web server's implementation does impose a limit; many popular implementations have default limits of 8K.  Servers SHOULD avoid setting a large number of large cookies such that the final cookie-string would exceed their header field limit.  Not doing so could result in requests to the server failing. </ins> Servers MUST be tolerant of multiple cookie headers.  For example, an <del> HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </del> <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114 client or intermediary might split a cookie header to improve compression.  Servers are free to determine what form this tolerance takes.  For example, the server could process each cookie header individually or the server could concatenate all the cookie headers into one and then process that final, single, header.  The server should be mindful of any header field limits when deciding which approach to take. Note: Since intermediaries can modify cookie headers they should also be mindful of common server header field limits in order to avoid sending servers headers that they cannot process.  For example, concatenating multiple cookie headers into a single header might exceed a server's size limit. </ins> 4.2.2.

Related discussion:
text: My question comes about because of some HTTP/2 code I looked at that simply implements HTTP/2 and so combines the multiple fields back into one. But as NAME and NAME alluded to their comments on , the splitting could be done for some reason thst isn't purely about H2 or H3 compression optimization. It seems there are actually use cases where keeping the split is useful, and not just in a private deployment. Of course relaxing things more might have unintended consequences. I find the current text too terse to be useful. This is a cookie spec, it seems like the right place to ba adding commentary about how to handle cookies across various version and conversions. Especially some anecdotal examples about why some clients actually do it.
Mentioning why a server should be tolerant, and what shape that could take, seems reasonable to me. Especially given how nicely it dovetails with . What forward reference are you referring to? ?
In that mention, I think it's worth including that re-combining the Cookie lines before passing to the next layer is a form of tolerance from the client's perspective.
Some more text sounds good and I'm happy to review. In Section 4.2.1:
Still LGTM, thanks!
Code change:
ua-requirements), the user agent will send a Cookie header field that conforms to the following grammar: <ins> While Section 5.4 of RFC9110 does not define a length limit for header fields it is likely that the web server's implementation does impose a limit; many popular implementations have default limits of 8K.  Servers SHOULD avoid setting a large number of large cookies such that the final cookie-string would exceed their header field limit.  Not doing so could result in requests to the server failing. </ins> Servers MUST be tolerant of multiple cookie headers.  For example, an <del> HTTP/2 RFC9113 or HTTP/3 RFC9114 connection might split a cookie header to improve compression. </del> <ins> HTTP/2 RFC9113 or HTTP/3 RFC9114 client or intermediary might split a cookie header to improve compression.  Servers are free to determine what form this tolerance takes.  For example, the server could process each cookie header individually or the server could concatenate all the cookie headers into one and then process that final, single, header.  The server should be mindful of any header field limits when deciding which approach to take. Note: Since intermediaries can modify cookie headers they should also be mindful of common server header field limits in order to avoid sending servers headers that they cannot process.  For example, concatenating multiple cookie headers into a single header might exceed a server's size limit. </ins> 4.2.2.

Related discussion:
text: Summarizes all the major changes from 6265bis, replacing the existing draft-by-draft change log.
While there are still a couple open issues that may/may not change this PR, I'd still appreciate an initial look. Thanks!
NAME This is ready for review, I don't believe the pending PR needs to be added to this changelog
Looks generally reasonable to me. Maybe drop the IANA changes summary (too detailed), and try to lead with the important changes (e.g., drop the errata down to last)?
It'd be nice if there were an appendix summarising the changes. We do this for most updates.
Sorry for being a bit dense but what is URL in comparison to that? :)
What's needed is a summary of changes from 6265, not for draft-by-draft. And that needs to stay in the spec upon publication.
NAME I see, thanks!
Is there a rule of thumb for which changes should be included? "Major" changes? Any normative changes? Something in between? Also, do you know of any existing RFCs that are a good example?
Major changes definitely, and any significant normative changes. See eg URL
Catching up on things after being out sick for a ~week. This change LGTM. I think the level of detail is appropriate, and I didn't see anything in the line-by-line changelog that jumped out at me as being big enough to consider missing.
Code change:
forward path) or doing so is explicitly allowed (e.g., by the max- stale request directive; see cache-request-directive). <del> A cache SHOULD generate a header field with the 110 warn-code (see warn.110) in stale responses.  Likewise, a cache SHOULD generate a 112 warn-code (see warn.112) in stale responses if the cache is disconnected. A cache SHOULD NOT generate a new header field when forwarding a response that does not have an header field, even if the response is already stale.  A cache need not validate a response that merely became stale in transit. </del> 4.3. When a cache has one or more stored responses for a requested URI,

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
4. <del> When using alternative services, both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. </del> <ins> When using alternative services, requests for resources identified by both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. </ins> Since "https" URIs rely on server authentication, a connection that is initially created for "http" URIs without authenticating the

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.