чт, 19 янв. 2023 г. в 23:41, <ma...@apache.org>:
changelog.xml
> index 7570715faa..9fd2f679a3 100644
> --- a/webapps/docs/changelog.xml
> +++ b/webapps/docs/changelog.xml
> @@ -125,6 +125,10 @@
> Implement the new Servlet API methods for setting character encodings
> that accept {@code Charset} objects. (markt)
> </add>
> + <update>
> + The default HEAD response no longer includes the payload HTTP header
> + fields as per section 9.3.2 of RFC 9110. (markt)
> + </update>
1. I think that you are actually referring to section 4.3.2."HEAD" of RFC 7231.
I do see words (an explicit "MAY") that allow such behaviour in
4.3.2.of RFC 7231,
but I fail to see them in 9.3.2 of RFC 9110.
I mean that RFC 7231 explicitly says
"except that the payload header fields (Section 3.3) MAY be omitted"
I do not see such words in RFC 9110.
and I do not see the term "payload HTTP header fields" (as mentioned
in our changelog) in RFC 9110.
I wish that RFC 9110 were more clear.
2. Trying to investigate, I see the following:
1) According to "B.3. Changes from RFC 7231" of RFC 9110, there was a
rename of terms:
[quote]
The terms "payload" and "payload body" have been replaced with
"content", to better align with its usage elsewhere (e.g., in field
names) and to avoid confusion with frame payloads in HTTP/2 and
HTTP/3. (Section 6.4)
[/quote]
2) A consequence is that "3.3. Payload Semantics" of RFC 7231 became
"6.4.1. Content Semantics " in RFC 9110.
The table listing "Payload header fields" in section 3.3 of RFC 7231
is gone in RFC 9110, and the term is gone.
3. I wonder whether it makes sense to make this feature configurable.
- I do not like it to be configurable, but I have a vague feeling that
I "know" about Content-Length header in responses to HEAD requests,
and that I used it for something, but I do not remember the details.
If one really used the value, I agree that such code (relying on a
Content-Length header received in response to a HEAD request) is
fragile. Has anyone seen such code in the wild?
- I agree that removing "Content-Length" and other headers makes
sense, as it aligns these responses with other no-content responses,
and as such makes behaviour more robust (and in this sense more
secure).
As such, it makes sense to backport it to earlier versions.
- It looks that we may omit any headers per 9.3.2. of RFC 9110, and
not only those four listed in 3.3 of RFC 7231:
First, 9.3.2. of RFC 9110 says "The server SHOULD send the same header fields",
It is "SHOULD", not "MUST".
Second, it mentions as an example that the "Vary" header may differ.
- Looking for examples in the wild,
https://stackoverflow.com/a/3854872
has an example of "Content-Length" / "Transfer-Encoding" headers being
present in responses generated in 2010.
4. Maybe keep this as is for Tomcat 11, but change the words in
changelog. They should not say "payload" when referring to RFC 9110,
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
