http: return Content-Length header for HEADs
#56681
Conversation
|
Review requested:
|
nodejs-github-bot
added
http
qwerzl
changed the title
Content-Length header for HEADsContent-Length header for HEADs
|
Can you add a test that covers this change? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #56681 +/- ##
=======================================
Coverage 89.20% 89.20%
=======================================
Files 662 662
Lines 191899 191934 +35
Branches 36940 36951 +11
=======================================
+ Hits 171184 171224 +40
Misses 13546 13546
+ Partials 7169 7164 -5
|
In the current http library, all responses without body will not return the Content-Length header. Fixes: nodejs#56680
qwerzl
force-pushed
the
fix/head-content-length
branch
from
4183136 to
8c4c5fc
Compare
@geeksilva97 Sure! I've modified the test file for |
There was a problem hiding this comment.
For the record, the specs do not require us to include this header.
8.6. Content-Length says:
A server MAY send a Content-Length header field in a response to a HEAD request (Section 9.3.2); a server MUST NOT send Content-Length in such a response unless its field value equals the decimal number of octets that would have been sent in the content of a response if the same request had used the GET method.
The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the content. For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain Content-Length and Vary fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency.
This PR aligns with the recommendations, but we might need to revisit this once HEAD will not touch the body and therefore will not know much about it.
The code LGTM with fixing linter error.
Also it would be great to have more specific test for this (for example, HEAD -> HEAD -> GET -> GET -> HEAD sequence of requests for different response bodies, making sure the value of Content-Length stays correct.
test/parallel/test-http-head-response-has-no-body-end-implicit-headers.js
Outdated
Show resolved
Hide resolved
Co-authored-by: Livia Medeiros <[email protected]>
| @@ -18,6 +19,8 @@ server.on('listening', common.mustCall(function() { | |||
| method: 'HEAD', | |||
| path: '/' | |||
| }, common.mustCall(function(res) { | |||
| assert.notStrictEqual(res.headers['content-length'], undefined, 'Expected Content-Length header to be present'); | |||
There was a problem hiding this comment.
Maybe check for an actual value rather than just making sure it's not undefined...?
| @@ -547,7 +547,7 @@ function _storeHeader(firstLine, headers) { | |||
| } | |||
|
|
|||
| if (!state.contLen && !state.te) { | |||
| if (!this._hasBody) { | |||
| if (!this._hasBody && this.req.method !== 'HEAD') { | |||
There was a problem hiding this comment.
If I'm understanding the logic correctly, the first if condition applies to those that should return neither of the Transfer-Encoding and Content-Length headers. While it's true for other requests that don't have a body, HEADs should match the 3rd condition (i.e. the !state.trailer && !this._removedContLen && typeof this._contentLength === 'number' one).
|
We should do a quick check if we are breaking anything in the ecosystem. |
In the current http library, all responses without body will not return the Content-Length header.
Fixes: #56680