On 20/01/2023 09:39, Konstantin Kolinko wrote:
чт, 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>
Thanks for the thorough review.
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.
The text in 9110 is
"...a server MAY omit header fields for which a value is determined only
while generating the content."
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.
Good point. I agree with your point below that the change log (and the
code comments) need an update.
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.
I'd only want to back-port it if we made it configurable.
- 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:
Not quite any header. See the RFC 9110 quote above.
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,
I'm really not sure about back-porting. This change was partly driven by
the changes in the HTTP spec and partly by the Servlet spec making
containers responsible for HEAD requests. There were lots of edge cases
in that and this simplifies some of those.
I'll update the comments now.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
