jiebi/CodeConvo huggingface dataset:
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

Related discussion:
text: As the cookie specification does not clearly define the behavior on localhost, we could consider reusing the notion of from the Secure Context specification, instead of suggesting a user-agent-dependent "secure protocol" check on the scheme of the request-URI, in point 13 of . Best regards
I think it's reasonable to modify the phrasing to include potentially trustworthy origins.
This is a good change, thanks. I don't think we have WPT in place for this (and I'm not entirely sure that we can?), but have you looked into the support for this change across browser engines? I'm generally in favor of landing it as long as it's reflecting (near) reality.
Code change:
Conformance criteria and considerations regarding error handling are defined in conformance. <del> 1.2. </del> <ins> 1.6. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234, extended with the notation for case-sensitivity

Related discussion:
text: I got distracted by old text and revised the introduction of semantics.
The introduction should reference the currently defined wire formats (1.1 and 2, also 1.0 maybe). We also need to figure out whether and where to mention differences: expect/continue transfer codings status phrase
Also, the current introduction to all three documents says: That needs to be adjusted to something like:
HTTP/1.2? Is there something you need to share with the working group, NAME
I think (but am not sure) that this has been covered by the changes made in Maybe NAME and NAME could have a look and see if the short HTTP/2 and HTTP/3 descriptions need more flowers.
I think that the number of flowers (->0) is entirely appropriate and I would be happy with those descriptions, with maybe a small tweak to the HTTP/3 text.
I left a review; once we resolve comments on the PR, I think this can be closed.
Some nits, but I like the direction generally.Awesome!
Code change:
negotiation. This document obsoletes RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC <del> 7615, and portions of RFC 7230. </del> <ins> 7538, RFC 7615, and portions of RFC 7230. </ins> Editorial Note

Related discussion:
text: Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.
Code change:
HTTP clients need to know that the content they receive on a connection comes from the origin that they intended to retrieve in from.  The traditional form of server authentication in HTTP has been <del> in the form of a single X.509 certificate provided during the TLS I- D.ietf-tls-tls13 handshake. </del> <ins> in the form of a single X.509 certificate provided during the TLS (RFC5246, I-D.ietf-tls-tls13) handshake. </ins> Many existing HTTP RFC7230 servers also have authentication requirements for the resources they serve.  Of the bountiful

Related discussion:
text: They were both special, but for some reason the first reference wasn't getting brackets in the text output. Putting whitespace between them doesn't affect that, but putting other characters does.
LGTM. (And yes, I tried whitespace as well :-)
Code change:
be met in a number of ways, which will vary based on specific deployments.  The communication between a TTRP and backend or origin server, for example, might be authenticated in some way with the <del> insertion and consumption of the "Client-Cert" header occurring only </del> <ins> insertion and consumption of the "Client-Cert" field occurring only </ins> on that connection.  Alternatively the network topology might dictate a private network such that the backend application is only able to accept requests from the TTRP and the proxy can only make requests to

Related discussion:
text: This was languishing in a PR within my repo, but since we've merged the actual draft, we can promote this to a PR in the main repo as well. (Yes, I'll rename the tag if we merge this as-is.)
Code change:
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  This digest-algorithm MUST NOT be used as it's now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </del> <ins> RFC4648.  This digest-algorithm is now vulnerable to collision attacks.  See NO-MD5 and CMU-836068. </ins> Reference: RFC1321, RFC4648, this document.

Related discussion:
text: [x] 5. I think you should come out and say that digest-algorithm values MUST be compared in a case-insensitive fashion. [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. [x] 5. There should not be RFC2219-MUSTs in IANA registry text. [x] This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."
[ ] 5. Also, is the entire checksum value case-insensitive, or just the token identifying the value? NAME the checksum value is defined by the digest-algorithm, which defines its case. [ ] 5- Also, these might be better placed in IANA Considerations. NAME can we just drop any mention of IANA in this section? I like it. [x] * 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there. NAME it is stated in the introduction URL . how would you specify it?
lgtm but keen to see mnot's approval too
Code change:
eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. <del> The server can choose whether it will process early data before the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </del> <ins> The server can reject early data.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded. The server can choose to delay processing of early data until after the TLS handshake completes.  By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein.  This provides the server with some </ins> assurance that the early data was not replayed. If the server receives multiple requests in early data, it can

Related discussion:
text: Our basic list of mitigations missed a fairly obvious one. Mentioning it should help with the class of confusion Magnus N. had with the draft. I decided not to include a note about the server being unable to examine early data before making this decision. That's just something people will need to discover for themselves. Generally, you have to decide whether you want 0-RTT without seeing any of it. Partly this is because it avoids a potential deadlock, but mostly it's because the TLS stack will not even decrypt 0-RTT if it is rejected.
Looks good to me, and indeed clearer. Thanks.
+1
Code change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234.  Additionally, the rule URI-reference is

Related discussion:
text: uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL
Code change:
3.4. <ins> A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (field.range).  After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per update. 3.5. </ins> A shared cache MUST NOT use a cached response to a request with an header field (field.authorization) to satisfy any subsequent request

Related discussion:
text: so it's adjacent to the other range-related requirements, rather than separated from them by the authenticated requirements.
Code change:
and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. <del> 8.3. </del> <ins> 8.5. </ins> <del> In HTTP/1.x, the pseudo-method CONNECT (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </del> <ins> The CONNECT method (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </ins> resources. <del> In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences.  Specifically: </del> <ins> In HTTP/2, the CONNECT method establishes a tunnel over a single HTTP/2 stream to a remote host, rather than converting the entire connection to a tunnel.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences. Specifically: </ins> A CONNECT request that does not conform to these restrictions is malformed.

Related discussion:
text: This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.
Code change:
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.

Related discussion:
text: ... 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).
Code change:
documented in any request for the working group to publish the specification. <ins> Publication might occur without multiple implementations if a single implementation is widely used, open source, and shown to have positive impact on the Internet, particularly if the target status is Experimental. </ins> 3.2. This document applies to proposals for congestion control algorithms

Related discussion:
text: Proposed resolutions
Appears ready to merge - but has conflicts I do not know how to resolve.
You could merge it as is, but I don't like the remaining passive form too much.
Code change:
2.5. <del> The signature base is a US-ASCII string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </del> <ins> The signature base is a US-ASCII (STD80) string containing the canonicalized HTTP message components covered by the signature.  The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in signature-params. </ins> Component identifiers are serialized using the strict serialization rules defined by STRUCTURED-FIELDS.  The component identifier has a

Related discussion:
text: Import obs-fold, reference US-ASCII, enforce ASCII-ness of Signature Base
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return items (which is empty). </ins> 4.2.5.

Related discussion:
text: This modifies parsing to consider empty or not-present header fields as empty containers; serialisation omits them from output.
The SH syntax does not directly allow empty field values, such as defined for Accept, although this might be allowed by field definitions like MyField = [ sh-list ] Likewise, the list types do not allow for empty lists. sh-list = list-member *( OWS "," OWS list-member ) list-member = sh-item I think this is a very odd choice for a generic syntax because the empty set is often given semantic meaning in generic communication. It's hard to do math without zero. If this is intended, the rationale should be explained in the spec, and there should be some discussion with examples about defining fields as an optional value.
FWIW, even if empty lists may be problematic top-level, the situation is different when they are nested...
ietf104 - interest in the room in supporting empty (perhaps null?) syntax
I agree this is something important. It may be used to mean "I know I must pass the info but I don't know the info", which is different from "I don't care about the protocol" or passing a dummy value just to fill the hole.
In the original base material of header definitions, empty values were generally just not sent at all. Having a specific Null value may or not make sense, not sure.
I personally like the distinction between "known to be empty" and "not presented either because I don't know or because it's empty". Some semantics might explicitly require the presence of some fields which we would enforce by the protocol. This doesn't mean they can't be empty, they must be present, for example, to make sure they weren't dropped in the middle. For example, "Connection: foo" gets rid of the field, not just the value. Just my two cents, Willy
Do we have any RFC'ed headers where there is a difference between a non-present and an empty header ?
There's an accept-something if I remember well. Also I've been using "Host:" in many occasions with HTTP/1.1 requests when I didn't know the host name and this tends to work where no Host field fails ;-) Willy
I'm not against a '?N' null token (along the lines of true/false), but I have a hard time thinking of a use for it.
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return items (which is empty). </ins> 4.2.5.

Related discussion:
text: URL
Wouldn't an empty list be equivalent to an empty value, thus we don't need a new syntax?
Putting an empty list where for instance an integer is expected, just to say that there will be none, sounds counter-intuitive to me.
On Fri, Apr 05, 2019 at 01:37:11AM -0700, Julian Reschke wrote: Indeed, probably.
On Fri, Apr 05, 2019 at 03:11:00AM -0700, Poul-Henning Kamp wrote: Agreed in general. My point was that sometimes specs use "MUST send" when the sender doesn't know, resulting in stupid values appearing. That's exactly what led a number of agents to place a content-length with stupid values (0 or huge ones) with the CONNECT method a long time ago. An empty value where an integer is needed by the application is more of an application-level error than a protocol-level one in my opinion : it's up to the application to decide how to recover from this missing piece of information (is it really needed to process the request or not). For me it can mean "don't care", "don't know" or "not representable". After all floats support "NaN" for the same reason :-) Willy
If there is a "MUST send" requirement, there must also be something available in the same spec that can be sent ?
There is not, and never has been, an interop problem with sending empty field values. They are a list value of zero items or a string item of zero length. Accept and Host, respectively.
NAME how do you know that?
Because if a recipient drops an empty Host field the request will be rejected with 400. There have been no reports of such breakage in 25 years. It isn’t even a likely scenario given how message fields are parsed and reproduced.
If a recipient doesn't drop an empty host header, the request will still be rejected with 400, surely? Regardless, I'd note that many headers address this situation with a reserved value like . Is there value in standardising on one such value for future headers?
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return items (which is empty). </ins> 4.2.5.

Related discussion:
text: I'm not convinced, but I'd note that we also have many headers that use to denote "all"; it seems to me that if we're going to do null, we should do that too (but again, I'm not convinced this is adding value).
On Mon, Apr 08, 2019 at 05:16:41PM -0700, Mark Nottingham wrote: It depends on the header field that was empty ;-) I've used the empty Host header field quite a bit (even in health check requests). My observation has been that while HTTP/1.1 without Host naturally causes a 400, HTTP/1.1 with empty Host is often processed similar to HTTP/1.0 without Host or as 1.1 with an unknown Host. I'd say "why not", but it's useful to consider lists and the iterative processing that can happen, removing one item at a time. Having to place a specific value to denote emptiness would require specific processing (i.e. check for emptiness after removing any item just for the sake of replacing it with the special value). By the way, speaking about lists makes me think we may complicate interop when a header field appears multiple times. For example if we have this in a request : List: a,b,c,d Foo: bar List: e,f,g,h It's not unreasonable to think that some simplified implementations may replace the first occurrence of List with "none" after processing it, leading to this : List: none Foo: bar List: e,f,g,h Or possibly this : List: none Foo: bar List: none Which may be processed as "List: none,e,f,g,h" or "List: none,none" respectively. Just my two cents, Willy
Willy, I think that would be clearly broken, and we should be able to catch it with tests. I think we're talking about all of the container types here (dict, list, list of lists, parameterised lists), correct? Julian, you gave as an example. Given that the behaviour recommended is exactly the same as if the header was missing, that's not very compelling. Besides the potential stripping issue (I have heard of implementations that strip empty headers, but don't have details on hand), some header libraries may not make a distinction between missing and empty headers.
Code change:
If input_string is empty, fail parsing. <del> No structured data has been found; fail parsing. </del> <ins> No structured data has been found; return items (which is empty). </ins> 4.2.5.

Related discussion:
text: Overall, I don't see a lot of value in accommodating empty headers directly, and I don't think we should be promoting it as a practice.
Agree, I'm not convinced either. I see the potential, but Gettys rule applies: "The only thing worse than generalizing from one example is generalizing from no examples at all." (May actually be from Phil Karlton originally, sources differ.)
Hm, no. "A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings." vs. "An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response."
Yes, but in the real world, the outcome is always the same.
No. HTTP/1.1 introduced an IESG requirement that Host must always be sent and recipients must always reject with 400 if Host is not received. When I pointed out that not all URIs have a host, the response was that clients must send an empty Host field in that situation. It is a MUST requirement in Semantics section 5.4: This is ingrained in HTTP semantics and commonly used by non-browser HTTP implementations. There is only one example of an HTTP header field using "none" and that is Accept-Ranges. It isn't a good example for anything. To be clear, it would be a bug for an HTTP message processor to drop a received header field just because the value is empty. Nothing about SH will change that. What we are discussing is whether SH is capable of representing an empty list or an empty header field, both of which it is currently incapable of doing.
If that spec specifically says "empty field-value", a SH "empty" token will not be usable for Host: anyway, and we're back in the "generalizing from no example at all" again.
On Thu, Apr 11, 2019 at 03:53:15PM +0000, Poul-Henning Kamp wrote: After having thought a bit more about this, I now think that we don't need empty list elements in the end because lists are not strongly ordered, they're not arrays with a position so an empty element in a list brings no value.