jiebi/CodeConvo huggingface dataset:
Code change:
While testing firefox's implementation of this draft Vlad determined that some versions of Chrome throw PROTOCOL_ERROR and close the connection if it receives a type 0xB frame with a non zero length on stream 0. Other frame type numbers, such as 0xC do not seem to have that problem. testing indicates this is fixed in version 59 and is a problem previous to that. (57 is in release as I write this). presumably this is related to historical code around BLOCKED which was proposed to use 0xB. Prudence says to just use a different code point for the moment.
Question for NAME and NAME should we somehow reserve 0xb to avoid this problem?
If this is fixed in Chrome 59, why bother? Actually, I'd also revert this change.
Neither. There are still old Chrome versions deployed (some people lag, for various reasons), so it's not safe to use now, but it should be in the not-to-distant future; we just need to wait a while to use it (presumably for another extension). Reserving it for all time would be a bad precedent.

Related discussion:
text: Frame Type: ORIGIN <del> Code: 0xb </del> <ins> Code: 0xc </ins> Specification: [this document]
Code change:
This changes Expect-CT to be a comma-separated list of directives (which may be name=value pairs), and adds some examples. Also allows the server to send multiple header fields so that they can be combined, as per URL Fixes issue ,
Would it be possible to include an example in the spec? Something like... Expect-CT: enforce; max-age=3600; report-uri="URL" As I believe most developers like to work with examples, rather than just using the spec definition as found under the heading "Response Header Field Syntax". :-)

Related discussion:
text: "delta-seconds" is used as defined in Section 1.2.1 of RFC 7234 RFC7234. <ins> 2.1.4. The following examples demonstrate valid Expect-CT response header fields: </ins> 2.2. This section describes the processing model that Expect-CT Hosts
Code change:
This changes Expect-CT to be a comma-separated list of directives (which may be name=value pairs), and adds some examples. Also allows the server to send multiple header fields so that they can be combined, as per URL Fixes issue ,
Would it be possible to include an example in the spec? Something like... Expect-CT: enforce; max-age=3600; report-uri="URL" As I believe most developers like to work with examples, rather than just using the spec definition as found under the heading "Response Header Field Syntax". :-)

Related discussion:
text: report to the specified "report-uri" as specified in reporting- expect-ct-failure. <del> If a UA receives more than one Expect-CT header field in an HTTP response message over secure transport, then the UA MUST process only the first Expect-CT header field. </del> The UA MUST ignore any Expect-CT header field not conforming to the grammar specified in response-header-field-syntax.
Code change:
... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).

Related discussion:
text: Abstract <del> This memo introduces an informational status code for HTTP that can be used for indicating hints to help a client start making preparations for processing the final response. </del> <ins> This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. </ins> Note to Readers
Code change:
... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).

Related discussion:
text: 1. <del> Most if not all of the web pages processed by a web browser contain links to external resources that need to be fetched prior to rendering the documents.  Therefore, it is beneficial to send such links as early as possible in order to minimize the time spent until the browser becomes possible to render the document.  Link header of type "preload" (Preload) can be used to indicate such links within the response headers of an HTTP response. However, it is not always possible for an origin server to send a response immediately after receiving a request.  In fact, it is often the contrary.  There are many deployments in which an origin server needs to query a database before generating a response.  It is also not unusual for an origin server to delegate a request to an upstream HTTP server running at a distant location. </del> <ins> It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use; for example, rendering HTML by a Web browser.  Having such links available to the client as early as possible helps to minimize perceived latency. The "preload" (Preload) link relation can be used to convey such links in the Link header field of an HTTP response.  However, it is not always possible for an origin server to generate a response header block immediately after receiving a request.  For example, the origin server might need to query a database before generating a response, or it might delegate a request to an upstream HTTP server running at a distant location. </ins> The dilemma here is that even though it is preferable for an origin server to send some headers as soon as it receives a request, it <del> cannot do so until the status code and the headers of the final HTTP response is determined. HTTP/2 (RFC7540) push can be used as a solution to the issue, but has its own limitations.  The resources that can be pushed using HTTP/2 are limited to those belonging to the same origin.  Also, it is impossible to send only the links of the resources using HTTP/2 push. Sending HTTP responses for every resource is an inefficient way of </del> <ins> cannot do so until the status code and the full headers of the final HTTP response are determined. HTTP/2 (RFC7540) server push can be used as a solution to this issue, but has its own limitations.  The responses that can be pushed using HTTP/2 are limited to those belonging to the same origin.  Also, it is impossible to send only the links using server push.  Finally, sending HTTP responses for every resource is an inefficient way of </ins> using bandwidth, especially when a caching server exists as an intermediary.
Code change:
... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).

Related discussion:
text: making preparations for processing the final response, and then run time-consuming operations to generate the final response.  The informational response can also be used by an origin server to <del> trigger HTTP/2 push at an caching intermediary. </del> <ins> trigger HTTP/2 server push at a caching intermediary. </ins> 1.1.
Code change:
... for your consideration; feel free to take, discard, or do whatever else you like :)
Thank you so much for the improvements. This PR is a tremendous opportunity for me to improve my skills (both in terms of writing a specification and in terms of English).

Related discussion:
text: 4. <del> If Early Hints is standardized, the HTTP Status Codes Registry should be updated with the following entries: </del> <ins> The HTTP Status Codes Registry will be updated with the following entry: </ins> Code: 103 Description: Early Hints <del> Specification: this document </del> <ins> Specification: [this document] </ins> 5.
Code change:
Fix one typo. Technically, a set is always a subset of itself. Therefore current wording implies that if two connections have identical Origin Sets, then neither should be used for new requests, and both should be closed. Fix this by saying "proper subset" instead of "subset".
Thanks!

Related discussion:
text: following ways: Clients MUST NOT consult DNS to establish the connection's <del> authority for new requests.  The TLS certificate MUST stil be used to do so, as described in RFC7540 Section 9.1.1. </del> <ins> authority for new requests.  The TLS certificate MUST still be used to do so, as described in RFC7540 Section 9.1.1. </ins> Clients sending a new request SHOULD use an existing connection if the request's origin is in that connection's Origin Set, unless
Code change:
Fix one typo. Technically, a set is always a subset of itself. Therefore current wording implies that if two connections have identical Origin Sets, then neither should be used for new requests, and both should be closed. Fix this by saying "proper subset" instead of "subset".
Thanks!

Related discussion:
text: over time, it is possible that a client might have more than one viable connection to an origin open at any time.  When this occurs, clients SHOULD not emit new requests on any connection whose Origin <del> Set is a subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. </del> <ins> Set is a proper subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. </ins> 3.
Code change:
The PR introduces a new SETTINGS parameter that can be used by a server to notify if (and how) it makes use of the CACHEDIGEST frames. You might find the discussion about how to use the parameter interesting. The text of the PR, under the assumption that the underlying transport will be TLS 1.3, suggests the client: to wait for SETTINGS parameter when doing a full handshake retain the value of the parameter in the TLS session cache and reuse the cached settings parameter value when doing 0-RTT resumption
Looks good to me, delta the one comment I made.

Related discussion:
text: 3. <ins> A server can notify its support for CACHE_DIGEST frame by sending the ACCEPT_CACHE_DIGEST (0x7) SETTINGS parameter.  If the server is tempted to making optimizations based on CACHE_DIGEST frames, it SHOULD send the SETTINGS parameter immediately after the connection is established. The value of the parameter is a bit-field of which the following bits are defined: FRESH (0x1): When set, it indicates that the server is willing to make use of a digest of freshly-cached responses. STALE (0x2): When set, it indicates that the server is willing to make use of a digest of stale-cached responses. Rest of the bits MUST be ignored and MUST be left unset when sending. The initial value of the parameter is zero (0x0) meaning that the server is not interested in seeing a CACHE_DIGEST frame. Some underlying transports allow the server's first flight of application data to reach the client at around the same time when the client sends it's first flight data.  When such transport (e.g., TLS 1.3 I-D.ietf-tls-tls13 in full-handshake mode) is used, a client can postpone sending the CACHE_DIGEST frame until it receives a ACCEPT_CACHE_DIGEST settings value. When the underlying transport does not have such property (e.g., TLS 1.3 in 0-RTT mode), a client can reuse the settings value found in previous connections to that origin RFC6454 to make assumptions. 4. </ins> This document registers the following entry in the Permanent Message Headers Registry, as per RFC3864:
Code change:
The PR introduces a new SETTINGS parameter that can be used by a server to notify if (and how) it makes use of the CACHEDIGEST frames. You might find the discussion about how to use the parameter interesting. The text of the PR, under the assumption that the underlying transport will be TLS 1.3, suggests the client: to wait for SETTINGS parameter when doing a full handshake retain the value of the parameter in the TLS session cache and reuse the cached settings parameter value when doing 0-RTT resumption
Looks good to me, delta the one comment I made.

Related discussion:
text: Specification: [this document] <del> 4. </del> <ins> This document registers the following entry in the HTTP/2 Settings Registry, as per RFC7540: Code: 0x7 Name: ACCEPT_CACHE_DIGEST Initial Value: 0x0 Reference: [this document] 5. </ins> The contents of a User Agent's cache can be used to re-identify or "fingerprint" the user over time, even when other identifiers (e.g.,
Code change:
The PR introduces a new SETTINGS parameter that can be used by a server to notify if (and how) it makes use of the CACHEDIGEST frames. You might find the discussion about how to use the parameter interesting. The text of the PR, under the assumption that the underlying transport will be TLS 1.3, suggests the client: to wait for SETTINGS parameter when doing a full handshake retain the value of the parameter in the TLS session cache and reuse the cached settings parameter value when doing 0-RTT resumption
Looks good to me, delta the one comment I made.

Related discussion:
text: Additionally, User Agents SHOULD NOT send CACHE_DIGEST when in "privacy mode." <del> 5.  References </del> <ins> 6.  References </ins> <del> 5.1.  URIs </del> <ins> 6.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
Code change:
. Since I wasn't sure if we can make normative references from an appendix, RFC5234 (ABNF) and RFC4648 (Base64) has been added as informative references.
NAME Thank you for your review. I believe that I have addressed all four issues in the commit above.
NAME Would it make sense to also describe the cookie-based method in this spec?
While we could do that, I am kind of negative against it. We need a specification for Cache-digest using HTTP/2 frames or HTTP/1 headers, since it needs to be defined as an interaction between a server and a client (that has the knowledge of what is being cached). OTOH, we do not need a specification for a Cache-Digest cookie, since it is totally controlled by the server. So it is entirely up to each server implementation to use whatever format it wants. Also, it is not easy to find out the right way to implement a cookie-based Cache-Digest that would work on all web browsers, since the timing the browser consumes the cookies sent from the server depend on the timing of the response. To summarize, the relatively low necessity and the technical difficulty makes me hesitate in pursuing the idea.

Related discussion:
text: 3. This draft currently has no requirements for IANA.  If the <del> CACHE_DIGEST frame is standardised, it will need to be assigned a frame type. </del> <ins> specification is standardised, the CACHE_DIGEST frame will need to be assigned a frame type and the Cache-Digest header will need to be registered. </ins> 4.
Code change:
The consequences for ORIGIN + Alt-Svc with a port change aren't awesome, but this should at least remove any confusion.
Are you going to take another go at this?
Sorry, I let this one drop because I missed your suggestion, which is good.
Thanks!

Related discussion:
text: The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. <del> By default, a connection's Origin Set is uninitialised.  When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain a single origin, composed from: </del> <ins> By default, the Origin Set for a connection is uninitialised.  When an ORIGIN frame is first received and successfully processed by a client, the connection's Origin Set is defined to contain an initial origin.  The initial origin is composed from: </ins> Scheme: "https" <del> Host: the value sent in Server Name Indication (RFC6066 </del> <ins> Host: the value sent in Server Name Indication (SNI, RFC6066 </ins> Section 3), converted to lower case Port: the remote port of the connection (i.e., the server's port)
Code change:
The consequences for ORIGIN + Alt-Svc with a port change aren't awesome, but this should at least remove any confusion.
Are you going to take another go at this?
Sorry, I let this one drop because I missed your suggestion, which is good.
Thanks!

Related discussion:
text: RFC6454, Section 6.2) and remove it from the connection's Origin Set, if present. <ins> When sending an ORIGIN frame to a connection that is initialised as an Alternative Service RFC7838, the initial origin set set will contain an origin with the appropriate scheme and hostname (since Alternative Services specifies that the origin's hostname be sent in SNI).  However, it is possible that the port will be different than that of the intended origin, since the initial origin set is calculated using the actual port in use, which can be different for the alternative service.  In this case, the intended origin needs to be sent in the ORIGIN frame explicitly. For example, a client making requests for "https://example.com" is directed to an alternative service at ("h2", "x.example.net", "8443").  If this alternative service sends an ORIGIN frame, the initial origin will be "https://example.com:8443".  The client will not be able to use the alternative service to make requests for "https://example.com" unless that origin is explicitly included in the ORIGIN frame. </ins> 2.4. RFC7540, Section 10.1 uses both DNS and the presented TLS certificate
Code change:
The consequences for ORIGIN + Alt-Svc with a port change aren't awesome, but this should at least remove any confusion.
Are you going to take another go at this?
Sorry, I let this one drop because I missed your suggestion, which is good.
Thanks!

Related discussion:
text: Set is a proper subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. <ins> The Origin Set is unaffected by any alternative services RFC7838 advertisements made by the server.  Advertising an alternative service does not affect whether a server is authoritative. </ins> 3. This specification adds an entry to the "HTTP/2 Frame Type" registry.
Code change:
The header needs to be registered if it's going to appear in an RFC. Looking at 7540, I think the frame type needs to be registered as well, since "Experimental Use" is private / local only.
Thank you very much!

Related discussion:
text: 2. <del> The CACHE_DIGEST frame type is 0xf1.  NOTE: This is an experimental value; if standardised, a permanent value will be assigned. </del> <ins> The CACHE_DIGEST frame type is 0xd (decimal 13). </ins> The CACHE_DIGEST frame payload has the following fields:
Code change:
The header needs to be registered if it's going to appear in an RFC. Looking at 7540, I think the frame type needs to be registered as well, since "Experimental Use" is private / local only.
Thank you very much!

Related discussion:
text: 3. <del> This draft currently has no requirements for IANA.  If the specification is standardised, the CACHE_DIGEST frame will need to be assigned a frame type and the Cache-Digest header will need to be registered. </del> <ins> This document registers the following entry in the Permanent Message Headers Registry, as per RFC3864: Header field name: Cache-Digest Applicable protocol: http Status: experimental Author/Change controller: IESG Specification document(s): [this document] This document registers the following entry in the HTTP/2 Frame Type Registry, as per RFC7540: Frame Type: CACHE_DIGEST Code: 0xd Specification: [this document] </ins> 4.
Code change:
This is a PR that essentially rebases the change proposed in . To me the change proposed by NAME is a clear improvement. I believe that we should merge this.
Regarding The requirement in the last sentence needs to be re-worded, since includes parsing and the client is clearly parsing those header fields and using them.
I would rewrite the paragraph as
Collision with my suggested edits; closing. Please ask to reopen if you still think there's a problem; we can address it in WGLC.

Related discussion:
text: containing the relation type "preload" and start fetching the target resource. <del> However, this MUST NOT affect how the final response is processed; when handling it, the client MUST behave as if it had not seen the informational response.  In particular, a client MUST NOT process the header fields included in the final response as if they belonged to the informational response, or vice versa. </del> <ins> However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational response itself (e.g., as metadata about the 103 (Early Hints) response). </ins> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103
Code change:
removes statements that are either redundant or contradicts with RFC 7230, 7231 clarifies how a server is expected to do when generating a response
While it is not required to specify how an intermediary might behave, doing so might be beneficial as suggested in URL We could possibly have something like the following below the example.
works for me.
NAME Thank you for the answer. Adopted the text (with nits) in d0903d6.
NAME Thank you for the review!
Looks good to me!

Related discussion:
text: client that the server is likely to send a final response with the header fields included in the informational response. <del> A server MUST NOT include Content-Length, Transfer-Encoding, or any hop-by-hop header fields (RFC7230, Section 6.1) in a 103 (Early Hints) response. </del> <ins> Typically, a server will include the header fields sent in a 103 (Early Hints) response in the final response as well.  However, there might be cases when this is not desirable, such as when the server learns that they are not correct before the final response is sent. </ins> A client can speculatively evaluate the header fields included in a 103 (Early Hints) response while waiting for the final response.  For example, a client might recognize a Link header field value containing the relation type "preload" and start fetching the target <del> resource. However, these header fields only provide hints to the client; they do not replace the header fields on the final response.  Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </del> <ins> resource.  However, these header fields only provide hints to the client; they do not replace the header fields on the final response. Aside from performance optimizations, such evaluation of the 103 (Early Hints) response's header fields MUST NOT affect how the final response is processed.  A client MUST NOT interpret the 103 (Early Hints) response header fields as if they applied to the informational </ins> response itself (e.g., as metadata about the 103 (Early Hints) response). <del> An intermediary MAY drop the informational response.  It MAY send HTTP/2 (RFC7540) server pushes using the information found in the 103 (Early Hints) response. </del> The following example illustrates a typical message exchange that involves a 103 (Early Hints) response.