jiebi/CodeConvo huggingface dataset:
Code change:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Related discussion:
text: attribute-name of "Path", and the cookie's path is "/". If the cookie-name is empty and either of the following conditions <del> are true, abort these steps and ignore the cookie: </del> <ins> are true, abort these steps and ignore the cookie entirely: </ins> the cookie-value begins with a case-insensitive match for the string "__Secure-"
Code change:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Related discussion:
text: NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, <del> such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </del> <ins> such as SSL or TLS, or if the host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a </ins> secure protocol and "localhost" to be trusted host. If the cookie's http-only-flag is true, then exclude the cookie
Code change:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Related discussion:
text: be enforced in set-cookie. Servers SHOULD use as few and as small cookies as possible to avoid <del> reaching these implementation limits and to minimize network bandwidth due to the Cookie header field being included in every request. </del> <ins> reaching these implementation limits, minimize network bandwidth due to the Cookie header field being included in every request, and to avoid reaching server header field limits (See server-syntax). </ins> Servers SHOULD gracefully degrade if the user agent fails to return one or more cookies in the Cookie header field because the user agent
Code change:
A number of minor misc changes and corrections to improve readability, usability, and consistency throughout the spec.
6265bis is nearly ready, but after years of changes there are probably some minor editorial issues that should be corrected. Someone (me) should proofread it and fix any problems found.
The RFC Editor will help with that.
Ah, good to know. I'll still give it a first pass to clean it up a bit.
LGTM.

Related discussion:
text: Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. <del> For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </del> <ins> For example, if a cross-site top-level request is made to a sensitive page that request will be considered cross-site and "SameSite=Strict" cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive "SameSite=Strict" cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are
Code change:
This PR clarifies a few things around the Upload-Limit field from : The last upload append request may now be smaller than the minimum append size specified in . For example, if a 510 MB upload is split into 100 MB requests, the last request can just be 10 MB. It clarified how a client can indicate the entire upload length when creating a new upload via the Content-Length header. The PR also mentions that no resumable upload resource may be created if the minimum size is not met, but the server might still accept and process the data (although without offering resumability) The Upload-Limit header is added to informational response in an example

Related discussion:
text: Integer. The "min-size" key specifies a minimum size for a resumable <del> upload, counted in bytes.  The server will not create an upload </del> <ins> upload, counted in bytes.  The server MAY NOT create an upload </ins> resource if the client indicates that the uploaded data is smaller <del> than the minimum size.  The value is an Integer. </del> <ins> than the minimum size by including the "Content-Length" and "Upload-Complete: ?1" fields, but the server MAY still accept the uploaded data.  The value is an Integer. </ins> The "max-append-size" key specifies a maximum size counted in bytes for the request content in a single upload append request
Code change:
This PR clarifies a few things around the Upload-Limit field from : The last upload append request may now be smaller than the minimum append size specified in . For example, if a 510 MB upload is split into 100 MB requests, the last request can just be 10 MB. It clarified how a client can indicate the entire upload length when creating a new upload via the Content-Length header. The PR also mentions that no resumable upload resource may be created if the minimum size is not met, but the server might still accept and process the data (although without offering resumability) The Upload-Limit header is added to informational response in an example

Related discussion:
text: The "min-append-size" key specifies a minimum size counted in bytes for the request content in a single upload append request <del> (upload-appending).  The server MAY reject requests below this limit and a client SHOULD NOT send smaller upload append requests. The value is an Integer. </del> <ins> (upload-appending) that does not complete the upload by setting the "Upload-Complete: ?1" field.  The server MAY reject non- completing requests below this limit and a client SHOULD NOT send smaller non-completing upload append requests.  A server MUST NOT reject an upload append request due to smaller size if the request includes the "Upload-Complete: ?1" field.  The value is an Integer. </ins> The "expires" key specifies the remaining lifetime of the upload resource in seconds counted from the generation of the response by
Code change:
Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.

Related discussion:
text: "ORIGIN", to allow servers to indicate what origins a connection is usable for. <ins> Additionally, experience has shown that HTTP/2's requirement to establish server authority using both DNS and the server's certificate is onerous.  This specification relaxes the requirement to check DNS when the ORIGIN frame is in use. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Code change:
Relax DNS requirements when ORIGIN is received Change the initial origin set to just SNI
wait - no. You wouldn't send the alternative in the ORIGIN frame, you would send the origin that you are the alternative for, right? that would make sense - if you want to use an alternative you can't rely on the SNI default.
this is indeed looking goodminor nitsThis is looking good.

Related discussion:
text: consider as members of the Origin Set (set) for the connection it occurs within. <ins> 2.1. </ins> The ORIGIN frame type is 0xb (decimal 11). The ORIGIN frame's payload contains the following fields, sets of
Code change:
Fixes URL
NAME could you take a look?
Comment by NAME This is rather unimportant, but I just wanted to mention it in case the authors find it useful. Feel free to ignore. The document states that there are no new security considerations, but that's perhaps not quite true. I think it might be useful to call out that an implementation cannot rely on its peer behaving correctly, so implementers will have to take into account they may still receive oversized frames from misbehaving clients. This is arguably no different from the situation today, so it can be argued that the current considerations are accurate. I just thought it might be useful to call it out so some engineer doesn't remove validation checks since the other side is supposed to behave now. Just because we have standards, doesn't mean that everyone complies.
RFC8878 says in its security considerations: Perhaps we could add something like: "Decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received." NAME Thoughts?
We could do something explicit like that, yeah. But I'm partial to just broadening the existing statement a little: This seems sufficient to me because this issue is called out explicitly in para 4 there (URL). What do you think, NAME NAME
Don't have strong opinions, but I think maybe adding a sentence explicitly about the window size limit is good, given the document is specifically about enforcing the window size limit. This will ensure nobody misses it even if they don't click through the reference to RFC8878.

Related discussion:
text: This document introduces no new security considerations beyond those discussed in RFC8878. <ins> Note that decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received. </ins> 5. 5.1.
Code change:
This is a partial revert of 5469d51 from PR
Talked with NAME a moment ago. I think there are some additional changes that will be necessary, but I don't object to the idea of this revert. Seems like a mistake in the original PR.
Happy to amend the PR if you can give me an idea of what additional changes are required.
I wrote up a change that should cover all the points we want to make. Namely, we still want UAs to accept that larger character set while encouraging server to use the more limited character set.
This looks reasonable to me, thanks to you both.

Related discussion:
text: header field as a set-cookie-string (defined below). NOTE: The algorithm below is more permissive than the grammar in <del> sane-set-cookie.  For example, the algorithm strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  In addition, the algorithm below accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie.  User agents use this algorithm so as </del> <ins> sane-set-cookie.  For example, the algorithm allows cookie-name to be comprised of cookie-octets instead of being a token as specified in sane-set-cookie and the algorithm accommodates some characters that are not cookie-octets according to the grammar in sane-set-cookie. In addition, the algorithm below also strips leading and trailing whitespace from the cookie name and value (but maintains internal whitespace), whereas the grammar in sane-set-cookie forbids whitespace in these positions.  User agents use this algorithm so as </ins> to interoperate with servers that do not follow the recommendations in sane-profile.
Code change:
Editorial stuff, mostly line wrapping and adjusting terminology. Happy to chat through it if you like.
thanks for this

Related discussion:
text: by the user (e.g. a force reload). The immutable extension only applies during the freshness lifetime of <del> the response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </del> <ins> the stored response.  Stale responses SHOULD be revalidated as they normally would be in the absence of immutable. </ins> <del> The immutable extension takes no arguments and if any arguments are present they have no meaning.  Multiple instances of the immutable extension are equivalent to one instance.  The presence of an immutable Cache-Control extension in a request has no effect. </del> <ins> The immutable extension takes no arguments.  If any arguments are present, they have no meaning, and MUST be ignored.  Multiple instances of the immutable extension are equivalent to one instance. The presence of an immutable Cache-Control extension in a request has no effect. </ins> 2.1.
Code change:
Editorial stuff, mostly line wrapping and adjusting terminology. Happy to chat through it if you like.
thanks for this

Related discussion:
text: corruption incidents.  These incidents include cache poisoning attacks.  Three mechanisms are suggested for mitigation of this risk: <del> Clients should ignore immutable for resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </del> <ins> Clients SHOULD ignore immutable from resources that are not part of an authenticated context such as HTTPS.  Authenticated resources are less vulnerable to cache poisoning. </ins> <del> User-Agents often provide two different refresh mechanismss: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, should ignore immutable as well. </del> <ins> User-Agents often provide two different refresh mechanisms: reload and some form of force-reload.  The latter is used to rectify interrupted loads and other corruption.  These reloads, typically indicated through no-cache request attributes, SHOULD ignore immutable as well. </ins> <del> Clients should ignore immutable for resources that do not provide </del> <ins> Clients SHOULD ignore immutable for resources that do not provide </ins> a strong indication that the stored response size is the correct response size such as responses delimited by connection close.
Code change:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Related discussion:
text: Let URL be the URL of the dictionary request. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=URL (see URLPATTERN-CLASS). </del> <ins> setting input=MATCH, and baseURL=URL (see URLPATTERN). </ins> If the hasRegExpGroups attribute of PATTERN is TRUE then return <del> FALSE (see URLPATTERN-REGEXP). </del> <ins> FALSE (see URLPATTERN). </ins> Return TRUE.
Code change:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Related discussion:
text: The "match-dest" value of the Use-As-Dictionary header is an Inner List of String values that provides a list of Fetch request <del> destinations for the dictionary to match (see REQUEST-DESTINATION). </del> <ins> destinations for the dictionary to match (see FETCH). </ins> An empty list for "match-dest" MUST match all destinations.
Code change:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Related discussion:
text: Let MATCH be the value of "match" for the given dictionary. Let PATTERN be an instance of the URLPattern class constructed by <del> setting input=MATCH, and baseURL=BASEURL (see URLPATTERN-CLASS). </del> <ins> setting input=MATCH, and baseURL=BASEURL (see URLPATTERN). </ins> Return the result of running the "test" method of PATTERN with input=URL which will check for a match between the request URL and <del> the supplied "match" URL Pattern (see URLPATTERN-TEST). </del> <ins> the supplied "match" URL Pattern (see URLPATTERN). </ins> 2.2.3.
Code change:
This makes it clearer what standard is being depended on, while still deep-linking to the right section of that standard. This generates citations like "see of ]". The "RequestDestination" part is free text in the attribute. I don't see a way to change the "Part" text. We can use the to rearrange it to "see ], )" if y'all prefer.
Great, thanks for the PR. It's a lot cleaner than a bunch of independent references.
NAME just filed, thanks. URL URL
NAME have you asked the WHATWG folks for stable anchors to those sections? See URL for details of how to do that.

Related discussion:
text: In browser terms, that means that both are either same-origin to the context they are being fetched from or that the response is cross- <del> origin and passes the CORS check (see CORS-CHECK). </del> <ins> origin and passes the CORS check (see FETCH). </ins> 9.3.3.
Code change:
adds more used definitions from HTTP.
representation metadata, content, ... in Conventions and Definitions.

Related discussion:
text: The terms Byte Sequence, Item, String, Token, Integer, and Boolean are imported from STRUCTURED-FIELDS. <del> The terms client and server are from HTTP. </del> <ins> The terms "representation", "representation data", "representation metadata", "content", "client" and "server" are from HTTP. </ins> 3.
Code change:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Related discussion:
text: 13. <del> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. </del> <ins> Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning thats that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14. <ins> Unlike "Content-Encoding" (see HTTP), "Transfer-Encoding" (see RFC9112) is a property of the message, not of the representation. Moreover. transfer codings can be applied in transit (e.g., by proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. 15. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.
Code change:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Related discussion:
text: resource.  This way, the integrity of an individual request can be protected. <del> 15. </del> <ins> 16. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This
Code change:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Related discussion:
text: an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 16. </del> <ins> 17. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may
Code change:
splits C-E and T-E sections clarifications quoted from HTTP and MESSAGING link to DIGEST-FIELDS appendix This PR contains some quotes from HTTP and MESSAGING. While they can be redundant, the previous wording made me think that they were not.
Transfer-Encoding does not affect the selected representation data, see URL Since it only apply to MESSAGING, it should be probably decoupled from a section addressing representation metadata (e.g., content codings): URL
Thank you very much!

Related discussion:
text: allowed to have, and restricting the length of time an upload resource can exist. <del> 17. </del> <ins> 18. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":