The first is an incorrect change -- "advance configuration" means configured prior to the request, not "advanced". The second is indeed a typo.
Roman Danyliw has entered the following ballot position for draft-ietf-httpbis-semantics-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: [x] ** Section 2.2. Per “Additional (social) requirements are placed on implementations …”, what’s a “social” requirement? Editors: removed in (URL)
[x] ** Section 4.2.2. http + https origins on the same host uniformly. Editors: added text in
[x] ** Section 5.1. Convention question. Per “Field names … ought to be registered within the …” HTTP field name registry, I have a question about the strength of the recommendation based on the use of the verb “ought” – is that RECOMMENDED? SHOULD? Section 8.3.1, 8.3.2, 8.4.1, 8.8.3, etc use a similar construct. Editors: we intentionally do not to use normative language for registration requirements.
[x] ** Section 7.2. Does this text allow for the possibility for both a Host and :authority be included? Editors: it's syntactically possible in H2 and H3. It's up to those specs to describe what that would mean.
[x] ** Section 9.2.1. In addition to example of the access logs files filling the disk, there could be significant CPU load if the target is a script. Editors: URL
[x] ** Section 17.1. The text provides helpful caution by stressing that “… the user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity. It seems that the integrity provided by DoT or DoH would also be relevant. Editors: added text in (see also URL)
[x] ** Section 17.2 people who run them; HTTP itself cannot solve this problem. No disagreement with the sentiment, but I would recommend not framing it in term of the trustworthiness of the people (i.e., intermediaries with poor security or privacy practices is not necessarily due to the lack of trustworthiness of the engineers operating the service; perhaps these services are also run in of jurisdictions where confidence in them should be reduced). NEW Users need to be aware that intermediaries are no more trustworthy that the entities that operate them and the policies governing them; HTTP itself cannot solve this problem. Editors: URL
[x] ** Section 17.5. More generically describe the attack OLD NEW Editors: d466398e
** Editorial
[x] -- Section 3.5. Should s/advance configuration choices/advanced configuration choices/? Editors: no, advance has the same meaning as "configuration choices made prior to request"
[x] -- Section 4.2.2. This text goes from referring to “secured” in the first sentence to “[acceptable] cryptographic mechanisms” in the second sentence. To link them, perhaps s/are secured/are cryptographically secured/ Editors: "secured" is a defined term for this spec.
[x] -- Section 6.5. Typo. s/section are are/section are/ Editors: URL
[x] -- Section 11.1. The text (at least when read as a .txt) isn’t showing RFC7617 or RFC7616 as references. Editors: it does in HTML: URL
[x] -- Section 14.1.1. Typo. s/gramar/grammar/ Editors: URL
disk, there could be significant CPU load if the target is a script. Yes. But this is the definition of "safe methods", not a discussion of all potential attack vectors of a server.
user's local name resolution service [is used] to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs.” The subsequent text highlights DNSSEC as improving authenticity. It seems that the integrity provided by DoT or DoH would also be relevant. Understood. Q: do we attempt an exhaustive list here, or just mention examples? If we did mention DoT and DoH, woulkd that be exhaustive?
By nature I don't think we can be exhaustive here. If anything, I'd replace DNSSEC with DoH, as it's getting more adoption (both in implementation and deployment) on the web.
http + https origins on the same host uniformly. We already say that in several places, and I don't think repeating ourselves helps the document become more readable or useful.
There are technical interop requirements for the protocol and social requirements to keep people safe on the Internet (or the Web safe from the people abusing it). This is just a short-hand version of old IETF lore, and probably isn't worth repeating in the spec.


LGTM.
Need to explain or reference explanation.
LGTM.
okay, I think this reads better, or we can split them into separate PRs if needed


I'm a little uneasy that the majority of headers that are prefixed with are actually scoped to the selected representation. E.g., , , , . The only registered, current headers that actually about the content (using the current definition in Semantics) are and , AFAICT. Not sure about ; it's defined in terms of the selected representation, but could equally be defined in terms of content, I suspect. It might help to add a small note to the that explains that the prefix doesn't necessarily imply that the header is strictly about the content. Also might be worth mentioning in the .
Reading semantics I have some doubts on C-L wrt partial representation this seems to be the full representation data (eg. see C-L + HEAD). But then what happens with value in a range response? The complete representation-data or the actual content?
"A Content-Length header field present in a 206 response indicates the number of octets in the content of this message, which is usually not the complete length of the selected representation. Each Content-Range header field includes information about the selected representation's complete length." So the case of a 206 response is special-cased.
It seems to me that C-L is more often used to convey "messaging" information, than the actual metadata (which happens only when HEAD is used).


Source:
It's completely irrelevant to the recipient what port number was used for an upstream intermediary, which is why it says MAY here.
There are two issues here: 1) The protocol-name doesn't reflect the scheme in use, for HTTPS, it's still 'HTTP'. The practical implication of that is that when HTTPS is used, the port needs to be explicit, even if it's the default for HTTPS. A clarifying note might help here. 2) HTTP/3 uses UDP, not TCP. Omitting 'TCP' from the MAY requirement might help.
This is for Via. HTTPS is not a separate protocol. "https" is a scheme that, among other things, doesn't allow an intermediary to forward HTTP messages until they are beyond the origin secured connection (and hence no longer HTTP/TLS). Whatever the post-TLS origin does to forward its messages via CDN or downstream origins is beyond the scope here.
Yes, we can just remove TCP from that sentence.
That would be acceptable.


For
[x] (7.6.3) Via "If a port is not provided, a recipient MAY interpret that as meaning it was received on the default TCP port, if any, for the received-protocol." So if received-protocol is "3", it's a UDP port. If received-protocol is "1" or "1.1", is the default port 80 or 443? IIUC the scheme isn't included to determine this. Editors: URL [x] (7.7) Message Transformations "A proxy that transforms the content of a 200 (OK) response can inform downstream recipients that a transformation has been applied by changing the response status code to 203 (Non-Authoritative Information)" Why not an normative word, instead of "can"? Editors: URL [x] (12.5.3) Is it correct that "identity" and having no field value for Accept-Encoding are synonymous? Editors: URL [x] "Servers that fail a request due to an unsupported content coding ought to respond with a 415 (Unsupported Media Type) status" Why not s/ought to/SHOULD ? Editors: URL [x] (14.3) Why can only origin servers send "Accept-Ranges: bytes"? Why not intermediaries? Editors: URL [x] (15.3.7) "A sender that generates a 206 response with an If-Range header field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? Editors: URL [x] (15.3.7.2) The last instance of THISSTRINGSEPARATES has a trailing '--'. If this is intentional, it ought to be explained. Editors: URL [x] (16.3.1) says field names SHOULD begin with a letter, but (16.3.2.1) says they SHOULD begin with "an alphanumeric character". More broadly, the "Field name:" description in (16.3.1) should probably refer to (16.3.2.1) unless I'm misunderstanding the scope of these sections. Editors: URL [x] (17.13) s/TCP behavior/TCP or QUIC behavior Editors: URL [x] (B) It would be good to mention here that accept-ext has been removed in (12.5.1), and accept-charset is deprecated in (12.5.2), if that is new to this spec. Editors: see URL and URL
Because it isn't required, nor is it widely implemented (if at all). We try not to make requirements that we know won't be honoured.
Because the header is information about the capabilities of the origin server, not other members of the request chain. Intermediaries can change (e.g., with proxy configuration). Note that a gateway (e.g., a CDN) is effectively acting as an origin server, so it can do this. The language in this section needs to be tweaked, however; there are a few instances of 'server' that should be 'origin server'.
field"... (13.1.5) leads me to believe that only clients can send If-Range. So how can there be a response with If-Range? It looks like the phrase 'to a request' was dropped somewhere between and now.
this is intentional, it ought to be explained. This is how multipart works; see . I don't think there's value in re-specifying it here.
As per the spec: ...
Because we avoid making existing servers that predate this spec non-compliant (unless there's a very good reason, such as security)


says: [...] says about : [...] Because we're saying that validation occurs against all responses for a given URI (see ), this has the effect of allowing a response with a header to update all of the responses sent for that URI in that second (provided the requirement about is met) -- which would lead to e.g., response with updating other languages. That probably isn't desirable. The obvious way to fix this is to avoid promoting to a strong validator when it's being used by a cache. However, see -- it's necessary for it to be strong for . It might also be worth refining caching 3.4.3 to differentiate between entity-tag updates and last-modified updates.
In 4.3.5, updating is done like this: Note that it's specified in terms of responses that could have been selected for that request, rather than "stored... responses for the applicable request URI." If we modified 4.3.4 to specify that responses that could have been selected for the request sent are updated (still subject to further filtering down by any validators in the 304 response), I think it should work.


Note that if we go in this directions, there are some editorial improvements in that we should pull in separately.
I find Roy's proposal more precise. The overall text does slightly help me find how to figure a scheme in H1.
From NAME - Let's discuss whether the currently specified procedures for reconstructing the target URI from a request-target in absolute-form provide adequate security properties, at the origin server. I'm specifically concerned about taking the scheme directly from the request target, i.e., making the distinction between the "http" and "https" schemes. The simple procedure of "take the scheme from the request-target" would seem to allow for the client to cause the server to engage processing for the "https" origin without receiving the protection that https is supposed to provide. (The converse case does not immediately seem to present much risk but is probably worth preventing as well on general principles of retaining consistency.) I don't remember seeing any text that would require the server to validate the scheme from the request-target against the actual properties of the transport (or the configured fixed URI scheme as might be provisioned with a trusted outbound gateway, etc.) While we do reference §7.4 of [Semantics] with a note that reconstructing the target URI is only part of the process of identifying a target resource, that part of [Semantics] does not mention scheme validation as part of rejecting misdirected requests. Does the origin server need to validate the scheme from an absolute-form request-target? What is the scope of consequences if it fails to do so?
I said: In 3.3 of 1.1 I was skimming by the initial text: The target URI is the request-target when the request-target is in absolute-form. ... whereas you obviously picked up on it. I agree that there's an issue here. The decisions about absolute-form requests were made way back when. My reading of the archive (circa September and October 1995 -- I'm sure those that were there will correct me) is that Host headers were added to address the multiple-hosts-on-an-IP problem in a way that was backwards-compatible with HTTP/1.0, but because some folks wanted to enable the use of URNs, proxies were required to support and use the absolute form, so that URNs could be (theoretically) resolvable through them. That didn't happen, but it is possible to use e.g., FTP through a HTTP proxy as a result (last I looked). I think the solution here is to restrict the statement above so that it only applies to proxies, and to add a requirement for origin servers (including gateways) to specifically check absolute-form URIs for alignment regarding the scheme.
It seems to me that the ability to do cross-protocol requests is a deliberate feature of HTTP, and not one we should interfere with now, even if it's rarely used. In fact, RFC 8164 explicitly relies on the ability to request "http" resources over an "https" connection. I agree that servers should not respond to requests that assume a secure channel over an insecure one. While Sections 4.2.2 and 4.3.3 seem to put most of the burden on the client not to make such requests, the server should probably consider such a request misdirected even if it is authoritative. Perhaps the least disruptive solution would be text in 7.4 adding https:// URIs received over insecure connections as another instance of a potentially misdirected request?
Before I get into the text, I need to clarify that this question is misplaced. The procedure for reconstructing the target URI is about reconstructing what the client sent. It is not about security (yet). It has nothing to do with ensuring the connection is secure. It is about understanding the request as received. AFTER the request is understood, the server needs to determine whether it can answer the request in that context. How it determines that is an internal configuration issue, not a protocol standard (because HTTP requests can arrive via any underlying transport), but there are things we can add to make the process clearer without assuming that all HTTP requests are made by general-purpose browsers.


replaces with my own edits. Note that I added "without revalidation" to the description of Vary since the cache can use the stored response, regardless of Vary, once it has been revalidated by the origin server (e.g., 304 with etag).
First changeset is pretty wordy...


This is related to the suggestion in but provides the modern reason why all servers work this way.
'This allows servers to be deployed in non-traditional configurations, such as within a custom service mesh or content distribution network, where the proxy/origin distinction is handled upstream.' I don't really buy this; suggest just removing this sentence.


Clarify that Accept-Ranges can be sent by any server, remove "none" from the ABNF because it is now a reserved range unit, and allow the field to be sent in a trailer section while noting why that is much less useful than as a header field For this is an alternative to
IMHO... allowing non-origins to service range requests, but disallowing them to advertise that is really really weird. At the end of the day, any "Accept-*" field value received is always a statement about the present, and not a promise for future requests. This is not different from other fields. Do you believe it would actually be harmful if a client was mislead to believe it can do a range request, and then it receives the full content with a 200?
A header field is defined by the intent of the people who minted and deployed it. That was Lou Montulli. Its original meaning was confused in the pre-RFC2068 draft because of an editorial mistake, not because the header field ever changed its meaning as deployed. The main use case was restarting a big download, and that is not specific to origin servers. Today, this field is largely ignored because of the poor specification. We can improve such things without harm.
I don't think this is worth too much more time, I'll just say I disagree -- it's not very useful in this form, and it differs from every other bit of similar metadata we put into headers (e.g., , , ). I'll make a suggestion to try to make the ambiguity here a bit more clear.
You are starting with an assumption that this is an origin characteristic and saying that this doesn't fit that assumption. I agree that the assumption does not fit the header field's definition, nor is it a fit for purpose. The field's purpose is to tell the client that range requests may help if there is a problem receiving the whole content. That's not limited to origin servers and has nothing in common with Allow or Vary. If a proxy cache can process range requests on large cached items (e.g., a company training video) and its clients can benefit from that, why would we not want to advertise that fact to the client? The theory that this may cause a problem with multiple paths just doesn't hold for proxies (they are client chosen) and wouldn't matter anyway for range requests because the worst case is a 200 response. This was explained in 1996 and the definition was fixed in the next draft. It just wasn't fixed enough. This doesn't change the fact that the header field isn't very useful, simply because it is advisory only and most clients will ignore that advice when it doesn't matter to them if 200 is the response. That's okay.


… might be allowed by consenting adults
My previous comment:
NAME you pushed back on MUST. My position is that our task is to define what's interoperable in HTTP, and bodies on GET clearly aren't. Using SHOULD here is a concession to a vocal minority who want to use the protocol in this way because they have pairwise agreements; I understand that if we use MUST here it'll be violated, but that puts the responsibility squarely and unambiguously on their shoulders. NAME point is valid -- if we use SHOULD, that ought (ha!) to be contextualised. To do so here, we'd need to write something like: The problem is that the message can still be handled by software that isn't party to or aware of that negotiation -- especially, intermediaries. So this isn't really something we should be encouraging. Hence, MUST.
I continue to disagree for the reasons you cited me above. Explaining the "SHOULD NOT" would work for me. If you want a change here, we might want to get those involved who actually use it in practice.
NAME please disambiguate 'above'.
The 'people who use it in practice' are not using HTTP -- they're building private protocols based upon it that don't interoperate with normal HTTP implementations. What they're doing breaks HTTP and HTTP implementations.
RFC 7231: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." I disagree that makes an implementation sending content "not HTTP". You are pushing for a change here, and I really believe you need better arguments to support that. If the intent is to discourage things like that, I'm all in, but using "MUST NOT" is not likely to achieve that goal.
We got here because the 7231 language was ambiguous enough that people misinterpreted it, so we added a RFC2119 requirement. Our AD is rightly pointing out that if we use SHOULD, we need to contextualise it with when it's acceptable to violate the requirement. What text do you propose to perform that function?
"A client SHOULD NOT generate content in a GET request, unless support for content is negotiated (in or out of band)." sounds good to me
As I explained above, that won't work. Out-of-Band negotiation isn't available to intermediaries. In-band negotiation is the SEARCH method (or whatever it ends up being called); it would be strange for the WG to allow other methods of negotiation when it's working on how to accommodate this properly. Also, while we place the requirement on the client here, realize that the impact here is really on the server -- it must not require a request to have a body in order to interoperate, because that precludes the client from using otherwise conformant HTTP implementations and infrastructure.
How so? Could you please clarify that? Are you saying that intermediaries are allowed to drop the payload? Where do we say that?
This discussion is not about future code, but about existing, deployed code which currently works for people, and which IMHO is not strictly forbidden by the existing spec. In past discussions, we agreed on strengthening how we discourage this, but a "MUST NOT" is very different from a "SHOULD NOT". For instance, do you expect HTTP libraries that currently support request bodies on GET to stop doing that, although there's production code relying on it?
No, I'm saying that the pressure we see to allow bodies on GET is being placed upon clients by servers who create services that use it, doing so because they read the current ambiguous language and find enough wiggle room to think it's allowed and a good idea. This is because the power dynamic between a client and server is often unbalanced, especially for APIs. It does not work in an interoperable fashion on the scale of the Internet - which is what we're documenting. Those are private agreements. The fact that it's not strictly forbidden is how we got here. Not any time soon, but those libraries aren't supporting HTTP in doing so; they're effectively supporting the creation of new, HTTP-derived protocols. How about:
Not following. It does work for some people (maybe because they use HTTPS or control the request path by other means). Saying that if something does not work "on the scale of the Internet" then it's not "HTTP" or shouldn't inform our spec does not work for me. If this was the case, we really would need to start removing many more pieces from the protocol. Also, telling libraries that they should stop supporting a use case that was allowed (with care) in RFC 2616 and 723x and which is used in practice doesn't look right to me. We are past WG LC and IETF LC; if you really really want to change this normative requirement now (instead of explaining the SHOULD), then you should get support for that on the mailing list.
What I mean is that if you create a resource that uses a body on GET, you can't just use any HTTP implementation - you have to find one that does bodies on GET. Here, 'implementation' includes the framework in use, the server software, reverse proxies, CDNs, description languages, etc. Likewise on the client side; it's no longer a HTTP service, in that I can use any HTTP client; I have to find one that supports this extra constraint. Furthermore for proxies I might want to use, etc. Effectively, it's HTTP+GETBODY, not HTTP. It's not an extension, because it's not backwards-compatible. You say it's "used in practice", but as far as I see it, it's a few large services using their popularity / market power to convince people to break the protocol. That ignores the security and interoperability issues that this practice brings. Practically no one uses , but that doesn't matter. This does. If you can suggest a qualification for the SHOULD that doesn't compound the problem, I'm all for it. Absent that, I'll take it to the list.
Also, looking at the text in situ, I think the current second sentence doesn't need modification, leaving the proposal as:
... and since we've tried to align this language in HEAD and DELETE, the change would also be made there.
I really disagree with changing this. There are enough mentions on the net about "what happens if I send a body with a GET" that it's pretty sure we're going to declare a few in-house deployments non-compliant. For example we could imagine that some local deployments use a request body for an auth scheme. We could even more imagine this with H2. And with H2-to-H1 gateways, the risk of seeing a request body with a GET is even higher. The real problem with this spec is that from the very early days we only say how to emit but much less what to receive, and that many implementors on the receive path tend to take the server's "MUST NOT" for granted and ignore corner cases. Marking a MUST NOT here would certainly re-open some smuggling issues just because some implementors would be less careful about this and would never check the presence of a content-length. So I definitely agree with Julian here, I'd rather keep the "SHOULD NOT unless negotiated by other means" at least to make sure everyone remains careful about this. Last, I'd rather not make GET such a special method after all the work we've done in 723x to try to uniformize processing for all of them! And as seen in a recent issue, at least both Apache and HAProxy deal fine with bodies in GET requests.
Maybe we split the difference -- there are certainly plenty of instances of "MUST NOT... unless..." in IETF specs.
I'm fine with this approach.
Am 16.07.2021 um 16:03 schrieb Mike Bishop: Hmmm. A "MUST NOT, unless..." really seems to be a "SHOULD NOT", no? Best regards, Julian
I think there's a difference, but it's subtle. "SHOULD NOT" implies that there are valid reasons you might choose to violate the spec, and describes what you should consider in making that choice. "MUST NOT unless" is an absolute prohibition outside of the described circumstance. I think Mark makes an excellent case for an absolute prohibition in the absence of prearranged support.
With that said, that will still declare all 723x-compliant gateways non-compliant, because they will emit this if they receive it. I'm really embarrassed by this last minute change considering the time spent on this during 723x before reaching that situation :-/
That is the very definition of a different protocol though. Why not just "MUST NOT" then?
It is HTTP. Is has not been forbidden in HTTP. It works in certain scenarios, and these are deployed. We can't undo that, even by "yelling". If we want to discourage people from doing this in new protocols, a "SHOULD NOT" wtih explanation is just right.
Right now you could use curl as the client, haproxy as the gateway and apache as the server and all of them would happily process this without a sweat because it properly respects the messaging. Regarding the semantics, it's up to the application making use of that to define it. Actually it is even already used and documented: the broadly used ElasticSearch explicitly documents how to perform JSON search requests using : URL So please let's stick to "SHOULD NOT" with Julian's "unless negotiated via other means" or something like this, instead of suddenly adding dangerous exceptions to the protocol and breaking interoperability between already deployed and working components.


[x] 10.2 note In Section 10.2 we had some good text cleanup (I think, prompted by one of my comments -- thank you!), but the removed text included a note about how the semantics of a response header field might be refined by the semantics of the request method and/or the response status code. That seems like it would be useful to have mentioned, and I'm not sure if this text was replicated elsewhere. Editors: The problem with that wording was that a field has defined semantics that include variations based on the context in which it appears, and those variations are included as part of the field definition (not refined by other parts of the specification). Ultimately, we decided that this doesn't need to be said in the section intro. [x] updating 3864 This document updates RFC 3864, which is part of BCP 90. However, this document is targeting Proposed Standard status, which means it cannot become a part of BCP 90 as part of that update. Did we consider splitting out the RFC 3864 updates into a separate, BCP-level, document, that would become part of BCP 90? Editors: The intended status for this document is full standard. The reason it updates RFC 3864 (which previously defined the registry for HTTP header fields as part of a registry for all application-level IMF-like protocols) is that IETF thinking has changed since 3864. Having a single IMF-wide definition of fields was unsuccessful and led to more confusion when fields diverged. Hence, this document is obsoleting only the HTTP parts of RFC 3864 by moving them back to the standards track. It is an update only because there is no status for partial obsoleting. [x] Section 1.2 the existing TLS and TCP protocols for exchanging concurrent HTTP messages with efficient field compression and server push. HTTP/3 ([HTTP3]) provides greater independence for concurrent messages by using QUIC as a secure multiplexed transport over UDP instead of TCP. My understanding was that h2 and h3 also use non-text-based headers, in contrast to HTTP/1.1's "text-based messaging syntax" that we mention earlier. Is that non-text nature worth noting here? Editors: No. This is not an overview of the differences between the protocols; just a brief introduction. [x] Section 3.7 organization's HTTP requests through a common intermediary for the sake of security, annotation services, or shared caching. [...] The term "security" can mean so many different things to different audiences that its meaning in isolation is pretty minimal. I suggest finding a more specific term for the intended usage, perhaps relating to an auditing, exfiltration protection, and/or content-filtering function. Editors: That is often how proxy-based products are sold/positioned in the market. [x] Section 3.7 as a transparent proxy [RFC1919]) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies. Is this text still accurate in the era of https-everywhere and Let's Encrypt? Editors: They are still deployed, yes. On a public access network, the first TLS request will fail. User agents recognize such failures and fall back to a plain HTTP access to a common URL, which is then intercepted by the filter and the user agent is directed to login for Internet access. You can see this in every hotel, cafe, and convention center. [x] Section 3.9 As Éric notes, OpenSSL 0.9.7l supports only SSL and TLSv1.0, which per RFC 8996 is no longer permitted -- I concur with his recommendation to update the example (potentially including Last-Modified). Editors: already addressed. [x] Section 4.2.x the target resource within that origin server's name space. Would a BCP 190 reference be appropriate here (emphasizing that the name space belongs to the origin server)? Editors: Not really. This section is defining what those components are for. BCP 190 is advice for specifications that assume certain hierarchies within applications. Most readers would find that to be an unnecessary distraction at best, or a circular down-reference at worst. [x] Section 4.2.2 within the hierarchical namespace governed by a potential origin server listening for TCP connections on a given port and capable of establishing a TLS ([RFC8446]) connection that has been secured for HTTP communication. [...] Is "capable" the correct prerequisite, or does the server need to actually do so on that port? (Given the following definition of "secured", though, the ability to successfully do so would seem to depend on the trust anchor configuration on the client, which is not really something the server can control...) Editors: "capable" is correct. As stated above that in 4.2, the server does not need to exist. [x] Section 4.3.3 authoritative response, nor does it imply that an authoritative response is always necessary (see [Caching]). Is it intentional that this paragraph diverges from the analogous content in §4.3.2 (which also mentions Alt-Svc and other protocols "outside the scope of this document")? Editors: Yes, it is intentional. It isn't necessary to repeat the Alt-Svc example, and the last sentence (for alternative access to "http" resources) is encompassed by the definition of "https" authority by certificate match. [x] Section 5.3 | Note: In practice, the "Set-Cookie" header field ([RFC6265]) | often appears in a response message across multiple field lines | and does not use the list syntax, violating the above | requirements on multiple field lines with the same field name. | Since it cannot be combined into a single field value, | recipients ought to handle "Set-Cookie" as a special case while | processing fields. (See Appendix A.2.3 of [Kri2001] for | details.) The reference seems to conclude only that the situation for "Set-Cookie" is underspecified, and doesn't really give me much guidance on what to do if I receive a message with multiple field lines for "Set-Cookie". (It does talk about the "Cookie" field and how semicolon is used to separate cookie values, which implies that "Cookie" would get special treatment to use semicolon to join field lines, but doesn't really give me the impression that "Set-Cookie" should also have such treatment.) Editors: Handling for Set-Cookie and Cookie are not defined by this specification; this is just an informative note. [x] Section 5.4 than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics. Is it worth saying anything about fields that the client does not recognize? (Per the previous discussion, the server needs to either know that the client recognizes the field or only send fields that are safe to ignore if unrecognized, if I understand correctly...) Editors: That's not relevant here. [x] Section 6.4.1 method and the response status code (Section 15). For example, the content of a 200 (OK) response to GET (Section 9.3.1) represents the current state of the target resource, as observed at the time of the message origination date (Section 10.2.2), whereas the content of the same status code in a response to POST might represent either the processing result or the new state of the target resource after applying the processing. Doesn't the last clause mean that there is some additional (meta)data that can affect the content's purpose (e.g., a Content-Location field)? Or how else would one know if the 200 POST response is the processing result vs the new state? It seems incomplete to just say "is defined by both" and list only method and status code as the defining factors. Editors: URL [x] Section 7.6.3 [I had the same question as Martin Duke about default TCP port, and the interaction with the scheme. I see that it has been answered since I initially drafted these notes, hooray.] [x] received target URI when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "". I found where (in the discussion of normalization in §4.2.3) we say to replace the empty path with "/" for non-OPTIONS requests. I couldn't find anywhere "above" where it was noted to replace an empty path with "" (presumably, for the OPTIONS requests), though. Editors: [x] Section 8.3 to disable such sniffing. "encouraged to provide a means to disable" could be read as also encouraging implementation of the (sniffing) mechanism itself. Is it actually the case that we encourage implementation of MIME sniffing? Editors: URL [x] Section 8.8.1 strong validator is unique across all versions of all representations associated with a particular resource over time. [...] My understanding is that, e.g., a cryptographic hash over the representation and metadata would be intended to be a strong validator, but for such a construction the "unique" property can only be guaranteed probabilistically. Are we comfortable with this phrasing that implies an absolute requirement? Editors: yes. [x] Section 8.8.4 SHOULD send the Last-Modified value in non-subrange cache validation requests (using If-Modified-Since) if only a Last- Modified value has been provided by the origin server. MAY send the Last-Modified value in subrange cache validation requests (using If-Unmodified-Since) if only a Last-Modified value has been provided by an HTTP/1.0 origin server. The user agent SHOULD provide a way to disable this, in case of difficulty. I'm failing to come up with an explanation for why it's important to specifically call out the HTTP/1.0 origin server in the latter case. What's special about an HTTP/1.1 origin server that only provided a Last-Modified value and subrange cache validation requests that makes the MAY inapplicable? (What's the actual expected behavior for that situation?) Editors: [x] Section 9.2.2 the server of multiple identical requests with that method is the same as the effect for a single such request. [...] I sometimes worry that a definition of idempotent like this hides the interaction of repeated idempotent requests with other requests modifying the same resource. A+A is equivalent to A, but A+B+A is often not equivalent to A+B... Editors: The definition of idempotent is about a single user agent's intent being repeatable (automatically retried on failure). The user's intent does not depend on the resource state unless the user makes it so using the conditional request mechanism defined in Section 13. We could add a forward reference here, but it is already discussed in 8.8. [x] Section 9.3.5 deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion. The specific phrasing of "only allow DELETE [...]" calls to mind (for me) an expectation of authorization checks as well. In some sense this is no different than for POST or PUT, and thus may not be worth particular mention here, but I thought I'd ask whether it makes sense to mention authorization (and authentication). Editors: Not worth particular mention. [x] Section 9.3.5 received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request. We had a similar paragraph earlier in the discussion of GET and HEAD, but those paragraphs included a clause about "close the connection because of its potential as a request smuggling attack" -- is DELETE not at risk of use for request smuggling? Editors: this has been fixed in a prior issue [x] Section 10.1.1 A server that responds with a final status code before reading the entire request content SHOULD indicate whether it intends to close the connection (e.g., see Section 9.6 of [Messaging]) or continue reading the request content. The referenced section seems to cover the "close" connection option, which is a positive signal of intent to close. Is the absence of that connection option to be interpreted as a positive signal of intent to continue reading the request content, or is there some other positive signal of such intent to continue reading? Editors: It is version specific. For example, HTTP/1.1 is persistent by default, so the absence of close is a positive signal. [x] Section 10.1.2 authentication. It seems that the level of security provided by the From header field is at most that of a bearer token, and that the natural choice of such token is easily guessable (though unguessable choices are possible). I'm having a hard time coming up with an IETF-consensus scenario where it would make sense to use From for access control or authentication (i.e., could this be MUST NOT instead?). Editors: already discussed as part of Francesca's feedback. [x] Section 10.1.3 denying links from other sites (so-called "deep linking") or restricting cross-site request forgery (CSRF), but not all requests contain it. I think we should say something about the effectiveness of Referer checks as a CSRF mitigation mechanism. Editors: That's a moving target that is often browser or organization-dependent. If we could get anyone to agree on a common opinion, let alone a common implementation, it might make an interesting BCP. [x] Section 10.1.3 Referer header field when the referring resource is a local "file" or "data" URI. A user agent SHOULD NOT send a Referer header field if This seems like a curious statement. Are we expecting future general-purpose user agents to emulate this behavior? If so, then why not recommend it explicitly? Editors: Referer policy is more under control of the W3C's WebAppSec WG; these are just general guidelines. [x] Section 10.1.3 request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent. A user agent MUST NOT send a Referer header field in an How does a referring resource indicate that Referer should be sent? Editors: Out of scope for this document. W3C defines referer-policy, but that's browser-centric. [x] Section 10.1.4 optional parameters (except for the special case "trailers"). Should the prose mention the 'weight' part of the t-codings construction (the "weight" production itself does not seem to be defined until §11.4.2)? Editors: URL [x] Section 10.1.5 For example, a sender might indicate that a message integrity check will be computed as the content is being streamed and provide the final signature as a trailer field. This allows a recipient to Please pick one of "message integrity check" and "signature" and use it consistently; these are both cryptographic terms of art (with different meanings). Editors: URL [x] Section 10.1.5 also be used by downstream recipients to discover when a trailer field has been removed from a message. It seems that this usage is only possible if sending the Trailer field is a binding commitment to emit the relevant trailer fields; otherwise the recipient cannot distinguish between a removal by an intermediary and a sender declining to generate the trailer field. Editors: 6ee7338d [x] Section 10.1.6 request unless specifically configured not to do so. (I assume that a reference to client-hints (or UA-CH) was considered and rejected.) Editors: yes. [x] Section 10.1.6 needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes ("fingerprinting"). client-hints might even be more appropriate as a reference here than it would be URL just in §17.13. Editors: CH is Experimental. [x] Section 10.2 It seems like it might be worth listing the fields already defined in the previous section (as request context fields) that can also appear as response context fields. Editors: Good catch. Trailer and Date are bidirectional fields, so it would be better to make a separate section for them, which would be either 10.1 or 10.3 (depending on on references in HTTP/3). [x] Section 12.2 Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation. Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension. I'm not sure that I understand how an HTTP extension would help specify a mechanism for automatic selection in reactive negotiation; isn't this just an implementation detail in the user-agent? Editors: Perhaps we should just remove "as an extension", since this isn't specific to HTTP? The URI and Alternates fields were proposed long ago for that purpose but did not attain sufficient implementation to remain in the standard. It is commonly implemented today using JavaScript in non-uniform ways. Likewise, HTML was extended to include the attribute on . [x] Section 12.5.1 | Note: Use of the "q" parameter name to control content | negotiation is due to historical practice. Although this | prevents any media type parameter named "q" from being used | with a media range, such an event is believed to be unlikely | given the lack of any "q" parameters in the IANA media type | registry and the rare usage of any media type parameters in | Accept. Future media types are discouraged from registering | any parameter named "q". This note seems like it would be more useful in the IANA media-types registry than "some random protocol specification that uses media types". Editors: same as URL [x] Section 12.5.3 Are these supposed to be multiple standalone examples or one single example with multiple field lines? (I note that they appear in a single element in the XML source.) If they are supposed to be one single example, I would have expected some remark about the combination of "" and ";q=0" (my understanding is that the q=0 renders codings not listed as unacceptable, even despite the implicitly q=1 wildcard). It seems that in other instances where we provide multiple examples in a single artwork, the prefacing text is "Examples:" plural, that makes some effort to disambiguate. Editors: URL [x] Section 12.5.3 | Note: Most HTTP/1.0 applications do not recognize or obey | qvalues associated with content-codings. This means that | qvalues might not work and are not permitted with x-gzip or | x-compress. This wording implies to me that there is a normative requirement somewhere else that qvalues cannot be used with x-gzip and x-compress, but I'm not sure where that would be. (It's also a bit hard to understand how x-gzip would be affected but not plain gzip, given that lists it as an alias for gzip ... additional restrictions don't quite match up with an "alias" nature.) Editors: This note reflects historical practice in 1996. Removed in URL [x] Section 12.5.4 an Accept-Language header field with the complete linguistic preferences of the user in every request (Section 17.13). This leaves me wondering how to improve on the situation and pick which subset of requests to send the header field in. I would expect that a blind random sampling approach would not yield privacy improvements over always sending them. Editors: this comment does not appear actionable. [x] Section 12.5.5 for selecting a representation varies based on aspects of the request message other than the method and target URI, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency. [...] I don't think I know what it means to "cross" a variance. The example (elided from this comment) about Authorization not needing to be included gives some hint as to what is meant, but I still don't have a clear picture. Editors: [x] Section 13.2.2 When the method is GET and both Range and If-Range are present, evaluate the If-Range precondition: if the validator matches and the Range specification is applicable to the selected representation, respond 206 (Partial Content) Otherwise, all conditions are met, so perform the requested action and respond according to its success or failure. I think that if the If-Range doesn't match, we're supposed to ignore the Range header field when performing the requested action, which doesn't seem to match up with this unadorned directive to "perform the requested action" (which would include the Range header field). (We might also change point (5) to use the "if true" phrasing that the other items use in the context of evaluating the precondition.) Editors: [x] Section 15.4.9 | Note: This status code is much younger (June 2014) than its | sibling codes, and thus might not be recognized everywhere. | See Section 4 of [RFC7538] for deployment considerations. This document obsoletes RFC 7538; if we believe that content is still useful we should probably consider incorporating it into this document. Editors: nope. We already here again and again that the spec is too long. Readers who care about these deployment issues can easily navigate to the reference spec. It's not required to understand the protocol. [x] Section 16.3.1 (appointed by the IESG or their delegate). Fields with the status 'permanent' are Specification Required ([RFC8126], Section 4.6). I would have expected IANA to ask for the phrase "Expert Review" to be used for the general case (if they did not already), since that's the relevant registration policy defined in RFC 8126. Editors: And yet, they did not. [x] [...] Reference to the document that specifies the field, preferably If the registration consists of "at least" a group of information that includes a specification document, doesn't that mean the policy is always "Specification Required", not just for permanent registrations? [x] Section 16.3.1 consultation with the community - the Expert(s) find that they are not in use. The Experts can change a provisional entry's status to permanent at any time. (The ability to freely convert a provisional registration to permanent seems to also require a specification document to always be present, even for provisional registrations.) Editors: no action evident. [x] Section 17 A few potential considerations that don't seem to be mentioned in the subsections: Implementation divergence in handling multi-member field values when singletons are expected, could lead to security issues (in a similar vein as how request smuggling works) Though ETag is formally opaque to clients, any internal structure to the values could still be inspected and attacked by a malicious client. We might consider giving guidance that ETag values should be unpredictable. When the same information is present at multiple protocol layers (e.g., the transport port number and the Host field value), in the general case, attacks are possible if there is not check for consistency of the values in the different layers. It's often helpful to provide guidance on which entit(ies) should perform the check, to avoid scenarios where all parties are expecting "someone else" to do it. Relatedly, the port value is part of the https "origin" concept, but is not authenticated by the certificate and could be modified (in the transport layer) by an on-path attacker. The safety of per-origin isolation relies on the server to check that the port intended by the client matches the port the request was actually received on. We mention that in response to some 3xx redirection responses, a client capable of link editing might do so automatically. Doing so for http-not-s responses would allow for a form of privilege escalation, converting even a temporary access into more permanent changes on referring resources. We make heavy use of URIs and URI components; referencing the security considerations of RFC 3986 might be worthwhile Editors: It is very late in the process to introduce such substantial text, especially when it would need additional review due to security impact. As this is a COMMENT, not a DISCUSS, we will not act upon this. [x] Section 17.1 For example, phishing is an attack on the user's perception of authority, where that perception can be misled by presenting similar branding in hypertext, possibly aided by userinfo obfuscating the authority component (see Section 4.2.1). [...] We might also mention "confusable" domain names here as well (which are possible even without resorting to IDNs). Editors: Same as above. [x] Section 17.5 Should we also discuss situations where there might be redundant lengths at different encoding layers (e.g., HTTP framing and MIME multipart boundaries), in a similar vein to URL ? Editors: Same as above. [x] Section 17.16.3 establishing a protection space will expose credentials to all resources on an origin server. [...] There's also not any clear authorization mechanism for the origin to claim use of a given realm value, which can lead to the client sending credentials for the claimed realm without knowing that the server should be receiving such credentials. Editors: This doesn't appear to be actionable. [x] Section 19.2 Should RFC 5322 be normative? We rely on it for, e.g., the "mailbox" ABNF construction. Editors: URL [x] Appendix A [Just noting that I did not attempt to validate the ABNF, since the shepherd writeup notes that they have been validated] [x] without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification. [x] Section 3.1 identified by a Uniform Resource Identifier (URI), as described in Section 4. [...] HTTP relies upon the Uniform Resource Identifier (URI) standard [RFC3986] to indicate the target resource (Section 7.1) and relationships between resources. Are these two statements compatible? (What is used for the non-URI resource identification scenarios?) Editors: the "most" is referring to the fact that some resources don't have explicit identifiers (as explained elsewhere). [x] Section 5.5 We seem to use the obs-text ABNF construction prior to its definition, which is in Section 5.6.4. Editors: URL [x] generate empty list elements. In other words, a sender MUST generate lists that satisfy the following syntax: Are the two formulations equivalent without some restriction on 'element' itself? [x] Section 6.4.2 If the request method is GET and the response status code is 200 (OK), the content is a representation of the resource identified by the target URI (Section 7.1). If the request method is GET and the response status code is 203 (Non-Authoritative Information), the content is a potentially modified or enhanced representation of the target resource as provided by an intermediary. If the request method is GET and the response status code is 206 (Partial Content), the content is one or more parts of a representation of the resource identified by the target URI (Section 7.1). If the response has a Content-Location header field and its field value is a reference to the same URI as the target URI, the content is a representation of the target resource. I count two "target resource" and two "resource identified by the target URI". Is there an important distinction between those two phrasings or could we normalize on a single term? Editors: c5db347 [x] Section 7.3.3 routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order. Editors: [x] is later than the server's time of message origination (Date). If I suspect some relevant details for this clock are covered in §10.2.2; maybe a forward reference would be useful. [x] Section 10.2 the target resource for potential use in later requests. I didn't see a previous enumeration of fields such that "remaining" would have meaning. (Also, the whole toplevel section seems to contain multiple sentences that are nearly redundant.) Editors: That text has been rewritten based upon other comments. [x] Section 10.2.2 [...] Are we using "with a clock" as shorthand for "have a clock capable of providing a reasonable approximation of the current instant in Coordinated Universal Time"? It might be worth clarifying if this different phrasing than above is intended to convey different semantics. Editors: [x] Authentication-Info, except [...] Is it worth calling out again that it can be sent as a trailer field, in case someone specifically goes searching for trailer fields? Editors: [x] Section 13.2.1 MUST ignore the conditional request header fields defined by this specification when received with a request method that does not involve the selection or modification of a selected representation, such as CONNECT, OPTIONS, or TRACE. We do say "can be used with any method" regarding If-Match, earlier, which is not very well aligned with this "MUST ignore". Editors: [X] Section 15.4 content-specific header fields, including (but not limited to) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, ETag, Last-Modified. The discussion in §8.8.3 seems to indicate that ETag is only used in responses, not requests, so I'm not sure in what scenarios it would need to be removed from the redirected request. Editors: [x] | Note:* In HTTP/1.0, the status codes 301 (Moved Permanently) | and 302 (Found) were defined for the first type of redirect | ([RFC1945], Section 9.3). Early user agents split on whether | the method applied to the redirect target would be the same as | the original request or would be rewritten as GET. Although | HTTP originally defined the former semantics for 301 and 302 | (to match its original implementation at CERN), and defined 303 | (See Other) to match the latter semantics, prevailing practice | gradually converged on the latter semantics for 301 and 302 as | well. The first revision of HTTP/1.1 added 307 (Temporary | Redirect) to indicate the former semantics of 302 without being | impacted by divergent practice. For the same reason, 308 | (Permanent Redirect) was later on added in [RFC7538] to match | 301. [...] I had to read this text several times to find a way to understand it that seems to make sense to me (but might still be wrong!). I think part of my confusion is that the word "former" is being used in two different senses (the first of the two choices, and the historical/earlier version). Perhaps it's more clear to just talk about "method rewriting" (and not rewriting) instead of using the overloaded term. Editors:
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).
Closing, as all remaining issues have been split out.
Since I put the effort in to track it down, I'll note for posterity that Francesca's corresponding feedback was item 14 at URL and bde626d7cdfd2a6221e1d2f4ec6c87f40dd8c7be is how it got addressed. (I had gotten confused about the relative timing of the respective reviews which prompted me to actually look at the history.)


…Control (
See URL
I think we might re-visit this advice, since CC is so widely implemented, but the errata is correct, so yes.


[x] Section 9.4 Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. nit: "Using larger number of multiple connections" doesn't seem right, and possibly in more ways than just the singular/plural mismatch. Editors: URL [x] trailers and chunked The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. Editors: The HTTP/1.1 message format does not allow adding trailers as a section following the message body. Trailers is allowed in chunked because the content itself is encoded into a format that concludes with an optional trailer section (within the message body). There is no possibility of generalizing this further for HTTP/1.x. [x] 2.2 trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation. Regardless, though, it seems like the text of the guidance as written (not quoted above) reads like it is setting us up for vulnerabilities in the presence of non-compliant (or HTTP/1.0?) implementations in the request chain. We might want to put in a bit more explanation of how the stated procedure avoids the vulnerability. Editors: [x] Section 3.2 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. [...] (I assume 301 rather than 308 was an intentional choice for maximum compatibility with old/broken clients.) Editors: This requirement existed long before 308 was minted. In any case, 301 would be preferred since we don't want to assume too much about why a non-GET request method is being used with an invalid request-line (usually meaning that the client failed to encode spaces in the hypertext reference). [x] Section 3.3 secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Is the contents of the TLS SNI extension sufficient request context to uniquely identify an intended authority? Editors: Maybe. Using a certificate that is specific to that authority (one that can't be shared by multiple origins and thus was definitely chosen by the client) would be sufficient. We don't need to define this further. [x] Section 5.1 does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value or after the last non-whitespace octet of the field line value ought to be excluded by parsers when extracting the field line value from a field line. I have in general tried to refrain from commenting on the extensive use of the phrase "ought to" in this group of documents, but this particular scenario seems like a strong candidate for a BCP 14 keyword. Editors: [x] Section 9.8 closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] This is written as if it's imposing normative requirements on generic TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... Editors: Rewritten by URL [x] Section 9.8 This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all the message data that it cares about. ...whereas this SHOULD does not have an obvious analogue in RFC 8446, and thus it would make sense to retain the BCP 14 keyword for. Editors: None of that reads well (it was imported from RFC2818). This is better rewritten as a factual statement of when it knows, as committed above. [x] Section 4 interpreted in light of the semantics defined for that status code. See Section 15 of [Semantics] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, In some sense it seems that the referenced status codes are defined by [Semantics], not "this specification". I was initially going to propose (in my PR) a change to "defined for", but that seems incorrect and I don't have a better proposal handy. Editors: URL [x] Section 5.2 (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] Since we don't include the obs-fold production as a component of any other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. Editors: I believe this is more than a nit. Opened URL [x] Section 9.2 MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non- 1xx) response. "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).


Please do :-)
[x] Section 9.4 Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. nit: "Using larger number of multiple connections" doesn't seem right, and possibly in more ways than just the singular/plural mismatch. Editors: URL [x] trailers and chunked The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. Editors: The HTTP/1.1 message format does not allow adding trailers as a section following the message body. Trailers is allowed in chunked because the content itself is encoded into a format that concludes with an optional trailer section (within the message body). There is no possibility of generalizing this further for HTTP/1.x. [x] 2.2 trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation. Regardless, though, it seems like the text of the guidance as written (not quoted above) reads like it is setting us up for vulnerabilities in the presence of non-compliant (or HTTP/1.0?) implementations in the request chain. We might want to put in a bit more explanation of how the stated procedure avoids the vulnerability. Editors: [x] Section 3.2 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. [...] (I assume 301 rather than 308 was an intentional choice for maximum compatibility with old/broken clients.) Editors: This requirement existed long before 308 was minted. In any case, 301 would be preferred since we don't want to assume too much about why a non-GET request method is being used with an invalid request-line (usually meaning that the client failed to encode spaces in the hypertext reference). [x] Section 3.3 secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Is the contents of the TLS SNI extension sufficient request context to uniquely identify an intended authority? Editors: Maybe. Using a certificate that is specific to that authority (one that can't be shared by multiple origins and thus was definitely chosen by the client) would be sufficient. We don't need to define this further. [x] Section 5.1 does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value or after the last non-whitespace octet of the field line value ought to be excluded by parsers when extracting the field line value from a field line. I have in general tried to refrain from commenting on the extensive use of the phrase "ought to" in this group of documents, but this particular scenario seems like a strong candidate for a BCP 14 keyword. Editors: [x] Section 9.8 closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] This is written as if it's imposing normative requirements on generic TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... Editors: Rewritten by URL [x] Section 9.8 This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all the message data that it cares about. ...whereas this SHOULD does not have an obvious analogue in RFC 8446, and thus it would make sense to retain the BCP 14 keyword for. Editors: None of that reads well (it was imported from RFC2818). This is better rewritten as a factual statement of when it knows, as committed above. [x] Section 4 interpreted in light of the semantics defined for that status code. See Section 15 of [Semantics] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, In some sense it seems that the referenced status codes are defined by [Semantics], not "this specification". I was initially going to propose (in my PR) a change to "defined for", but that seems incorrect and I don't have a better proposal handy. Editors: URL [x] Section 5.2 (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] Since we don't include the obs-fold production as a component of any other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. Editors: I believe this is more than a nit. Opened URL [x] Section 9.2 MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non- 1xx) response. "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).
suggestion


…to explain better for
[x] Section 9.4 Furthermore, using multiple connections can cause undesirable side effects in congested networks. Using larger number of multiple connections can also cause side effects in otherwise uncongested networks, because their aggregate and initially synchronized sending behavior can cause congestion that would not have been present if fewer parallel connections had been used. nit: "Using larger number of multiple connections" doesn't seem right, and possibly in more ways than just the singular/plural mismatch. Editors: URL [x] trailers and chunked The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. Editors: The HTTP/1.1 message format does not allow adding trailers as a section following the message body. Trailers is allowed in chunked because the content itself is encoded into a format that concludes with an optional trailer section (within the message body). There is no possibility of generalizing this further for HTTP/1.x. [x] 2.2 trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation. Regardless, though, it seems like the text of the guidance as written (not quoted above) reads like it is setting us up for vulnerabilities in the presence of non-compliant (or HTTP/1.0?) implementations in the request chain. We might want to put in a bit more explanation of how the stated procedure avoids the vulnerability. Editors: [x] Section 3.2 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. [...] (I assume 301 rather than 308 was an intentional choice for maximum compatibility with old/broken clients.) Editors: This requirement existed long before 308 was minted. In any case, 301 would be preferred since we don't want to assume too much about why a non-GET request method is being used with an invalid request-line (usually meaning that the client failed to encode spaces in the hypertext reference). [x] Section 3.3 secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Is the contents of the TLS SNI extension sufficient request context to uniquely identify an intended authority? Editors: Maybe. Using a certificate that is specific to that authority (one that can't be shared by multiple origins and thus was definitely chosen by the client) would be sufficient. We don't need to define this further. [x] Section 5.1 does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value or after the last non-whitespace octet of the field line value ought to be excluded by parsers when extracting the field line value from a field line. I have in general tried to refrain from commenting on the extensive use of the phrase "ought to" in this group of documents, but this particular scenario seems like a strong candidate for a BCP 14 keyword. Editors: [x] Section 9.8 closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] This is written as if it's imposing normative requirements on generic TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... Editors: Rewritten by URL [x] Section 9.8 This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all the message data that it cares about. ...whereas this SHOULD does not have an obvious analogue in RFC 8446, and thus it would make sense to retain the BCP 14 keyword for. Editors: None of that reads well (it was imported from RFC2818). This is better rewritten as a factual statement of when it knows, as committed above. [x] Section 4 interpreted in light of the semantics defined for that status code. See Section 15 of [Semantics] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, In some sense it seems that the referenced status codes are defined by [Semantics], not "this specification". I was initially going to propose (in my PR) a change to "defined for", but that seems incorrect and I don't have a better proposal handy. Editors: URL [x] Section 5.2 (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] Since we don't include the obs-fold production as a component of any other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. Editors: I believe this is more than a nit. Opened URL [x] Section 9.2 MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non- 1xx) response. "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).


In semantics 7.7: I found where (in the discussion of normalization in §4.2.3) we say to replace the empty path with "/" for non-OPTIONS requests. I couldn't find anywhere "above" where it was noted to replace an empty path with "*" (presumably, for the OPTIONS requests), though.
This is a reference to text that was moved to HTTP/1.1 because it is version specific. I suggest we replace it with
LGTM


This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho


Note that this also rephrases the SHOULD requirement, but doesn't change its effect.
As mentioned in ... >Section 12.5.5


From : without a concept of modification time. (Section 13.1.4) I couldn't really locate which text was supposed to be providing this clarification.
Re: Appendix B.4 -- This text originally referred to the resolution of , but that was subsequently overwritten when we aligned the way we specified conditionals. It probably needs to be re-introduced (and perhaps looked at for the other conditionals).


In Section 7.3.3 (as noted by ) If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an origin for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification. This document is the relevant specification for the "http" and "https" URI schemes; a section reference to the corresponding procedures might be in order.
This was already implied, but it does read better if we close the loop on routing by sending the request message with the identified request target.


For
Registration requests consist of at least the following information: [...] Specification document(s): Reference to the document that specifies the field, preferably If the registration consists of "at least" a group of information that includes a specification document, doesn't that mean the policy is always "Specification Required", not just for permanent registrations?
I think the intent here was to encourage but not require a specification for provisional registration. Will PR.


This goes back to URL
Simplest possible fix would be to mark it as allowed in trailers as well.


Me confused. Which PR is relevant now? Both?
The other one is an evolution of this one.
We use the phrases 'selected representation' and 'selected response' in Semantics and Caching (respectively) to refer to two completely different concepts. Can we do better?
No
I think the two concepts match pretty well (and are used correctly in the four sentences). However, I also think that "chosen response" would be okay given it is only used in four places. I really don't think it needs a separate definition, since it means what the two words mean. So, maybe.
It was actually used in a few more places as the response selected. I think I found all of them.
See .


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


Reviewer: Marco Tiloca Review result: Ready with Nits Thanks for this document! I have found it very well written and I believe it's basically ready. Please, see below some minor comments and nits. Best, /Marco [X] [Section 1.2] As to "absolute-path", it is more precise to point to Section 4.1 of [HTTP]. Editors: URL [X] [Section 3] "HTTP does not place a predefined limit on the length of a request-line, as described in Section 2 of [HTTP]" This can better point to Section 2.3 of [HTTP]. Editors: URL [X] [Section 3.2] "A client MUST send a Host header field in all HTTP/1.1 request messages." This sentence can be expanded to point to Section 7.2 of [HTTP]. "... excluding any userinfo subcomponent and its "NAME delimiter ..." This should point to Section 4.2.4 of [HTTP]. Editors: URL [X] [Section 3.3] "Alternatively, it might be better to redirect the request to a safe resource that explains how to obtain a new client." Is "client" actually the intended word here? Or is it about using redirection to explain the client how to obtain something else (e.g. a proper authority component for a follow-up request) ? Editors: client is the intended word here: this case is only possible if the client sent an HTTP/0.9 or HTTP/1.0 request without a Host header field, which should not be in any deployed client since 1995. [X] [Section 7.1.2] I believe it's better for the reader if the last paragraph is split into 2 or 3 sentences Editors: [X] [Section 9.8] "When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received ..." Shouldn't this be about received responses? Or does it refer to the completion of the exchanges started by the mentioned requests? Editors: yes, it's about the completion of the exchanges. [X] [Appendix A] The first paragraph can better point to Section 5.6.1 of [HTTP]. Editors: URL The reference for "absolute-path" should be Section 4.1 of [HTTP]. Editors: URL
Long indeed. NAME - do you want to give that a try?


The text in the document says: The Media Type Designated Experts' suggested to make that stronger, and have the following note on the : Let's agree on either "discouraged" or "prohibited", and align the text in the document and in the IANA registry note.
I believe what the IANA registry says is good, so what's left to do is to align our spec text with that. My understanding is that no new text in the IANA Considerations is needed, as the change to the registry already happened.
If we agree to add the reference to this RFC in the IANA note, once the RFC is published, I can ask IANA to do that.
Good point. We could add that to the IANA Considerations. Should I?
I think that would make sense. Let's hear from others.


Inspired by my ballot comments ( ) I started trying to write something about how it's required to send "close_notify" in normal connection shutdown, but didn't like how that worked, and ended up here. I am not sure if I regressed in some other axes while improving on this one, though.


The follow-up discussion on indicated that the nature of the updates to RFC 3864 is essentially a "partial obsoletes", which means that we do not want to be part of BCP 90 even if we could -- we're carving off a piece of it and branching out on our own. This PR attempts to reword the description slightly to indicate that we're not just tweaking part of RFC 3864, but rather replacing part of it (the parts that relate to HTTP), hopefully without bloating the text too much.


Inspired by some discussion on : while just the word "security" is indeed used in marketing literature for proxies, it's meaning to different parties is so varied so as to not really convey much useful information. In the IETF we try hard to be clear about what security provides we need and/or provide, avoiding the vague catch-all term. However (as I am reminded out of band), the audience of this document is not exactly security experts, and it is easy to go overboard trying to be precise, at least in this instance. [actual commit message body retained below] The mere act of inserting a proxy into the chain does not, in and of itself, do much of anything for the security of the system (and a badly implemented proxy can make the security of the system much worse). A proxy can, however, provide security services such as auditing access, annotating content from untrustworthy sources, exfiltration avoidance, etc. It is these services that are the security-related motivation for using a proxy, so say that "security services", rather than just "security", are being provided by the proxy.


It may or may not be useful to have an HTTP extension in order to perform reactive negotiation -- one possible approach that does not require an extension would be policy in the user-agent. In the spirit of "less is more", and to not overly constrain our forward-looking statement, just remove the phrase "as an extension". (inspired by follow-up discussions on )
I almost made the same edit earlier.


The current text of "ought to ... where possible" is easy to read as saying "if you have the technical capability, do it". There are, however, some subtleties, such as if you get the 308 response over http-not-s, in which case the question of whether or not to re-link is not so clear-cut. Change from "where possible" to "where appropriate" to hint that there is some logic needed here beyond "blindly accept". (inspired by follow-up discussions from )
I like Roy's version better than mine :) I guess I was too conservative...
I think that begs a follow-on question about when it is appropriate. I would be more comfortable with changing the entire sentence to be The change itself is good, but it needs to be done for 301 as well.


Inspired by follow-up discussions on , make a concrete proposal for how the RFC 3986 security considerations might be mentioned in our own security considerations. I understand the editors' stance on adding substantial new text at this point, and will defer to them on whether this constitutes "substantial".


note in message-headers registry above move of HTTP registry in message-headers registry, remove obsolete note about HTTP field name registry note in new http field registry


Should we mention this on the mailing list?
Sure.
specified that identity content-coding could be made unacceptable (e.g., indicating very strong preference for response compression) by means of an Accept-Encoding request header field value like or without an identity-specific preference, and then recommended that the server SHOULD respond with 406 (Not Acceptable) when it cannot send an acceptable response. But and the update that last point to "SHOULD send a response without any content-coding", presumably primarily intended to avoid sending 406 (Not Acceptable) when the acceptability of identity content-coding is unspecified. The text still includes a description of when identity content-coding is unacceptable and still accommodates a "compression is mandatory" interpretation of , but seems to strongly discourage it in the sense of ("there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course"). I suspect this to be unintentional, and would propose clarification in semantics: In the absence of such clarification, the text describing when identity content-coding is unacceptable seems to be largely pointless.
I agree that this is not optimal, but the proposed text would change the protocol from what is has been since RFC 7231. Given that the current draft is approved and in the publication queue, I don't think that a change is possible or even desirable.
The move away from sending 406 was intentional in RFC7231. There is no implementation support for identity;q=0 overriding basic interoperability (200 response without encoding), unlike Accept for unwanted media types, because encodings are often applied late in the request handling process based on the server's analysis of whether they are efficient/possible. Hence, clients simply list the acceptable encodings and variance in the field values cause unwanted cache misses. The feature only made sense for non-compression encodings. This does not prevent a server from responding with 406, but doing so is less interoperable (without some additional knowledge about why the client is asking for that) than sending no encoding.
If it is indeed intentional for absence of content coding to always be considered acceptable, then what is the purpose of keeping (emphasis mine)?
I meant that the move away from 406 was intentional. Suggesting that "identity;q=0" not be respected was not intentional, but is also not implemented AFAIK (It only makes sense for encryption-related encodings). I would suggest a less normative fix, like and just send that now to the RFC editor as a clarification.
Great, thanks!
NAME - are you going to create a PR for this?
LGTM