Allow missing HEAD content length

[GrahamCampbell]

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Related tickets	none
Documentation	n/a
License	MIT

What's in this PR?

This relaxes the request assertion for HEAD requests so a client may omit Content-Length when the server did not receive one. The assertion still checks Content-Length when a client sends it, and keeps the existing TRACE behavior.

Why?

The test suite currently makes Content-Length mandatory for HEAD requests because the default request headers include Content-Length: 0, and bodied test cases replace it with the body length. That is too strict for clients and transports that intentionally suppress HEAD request content.

If such a client kept a positive Content-Length while sending no body, the wire message would declare bytes that never arrive, which can make servers wait for the missing request body or corrupt connection framing. A missing Content-Length is valid for a HEAD request with no transmitted content, and this change only tolerates that absence; it still validates the header value when a client sends one.

Guzzle needs this while fixing guzzle/guzzle#3728 because its cURL handler must use cURL's no-body mode for HEAD requests to avoid waiting for response bodies that valid HEAD responses do not send. That mode suppresses request uploads, so Guzzle also has to omit positive request Content-Length values rather than send misleading framing headers.

Checklist

• Updated CHANGELOG.md to describe BC breaks / deprecations | new feature | bugfix
• Documentation pull request created (if not simply a bugfix)

[dbu]

https://datatracker.ietf.org/doc/html/rfc9110#name-head describes the expected server behaviour. it tells that the server SHOULD send the content-length so that the client can use that information, but it is optional.

the RFC does not define how a HTTP client abstraction has to behave, but to me it seems bad design to discard the header if the server sent it. as the client knows it did a HEAD request, it should be able to not wait for the content, as RFC9110 explicitly states that the server MUST NOT send any content.

as this test controls the server, we do send the content-length header. did you change guzzle to discard content-length from HEAD requests? is there no better solution?

[GrahamCampbell]

Thanks for the review @dbu. A clarification: this assertion is on the request the server receives, so it's the request Content-Length the client sends, not the response header. Nothing here discards the server's response Content-Length. That's still preserved and used, which is how the client knows not to wait for the body.

The Guzzle fix is guzzle/guzzle#3729: HEAD now always uses cURL's no-body mode. No-body mode also suppresses the request upload, so sending a positive request Content-Length would announce bytes that never arrive and the server would block on them. So Guzzle keeps Content-Length: 0 (if one exists) but drops a positive one when it isn't sending a body. That's why the test needs to allow a missing request Content-Length on HEAD, same as TRACE already does. It's scoped to the absence case and still checks the value whenever a client does send one.

[dbu]

ah, sorry i misunderstood. now i had a closer look. so this is about the HEAD requests the client sends. then that makes sense.

i think i was confused by the PR description:

a client may omit Content-Length when the server did not receive one.

i will add something to the changelog to say that the client is allowed to omit the content-length in the HEAD request it sends.

[dbu]

thank you. i tagged 3.2.1 and 4.1.1 with this fix

[GrahamCampbell]

🚀