spin
spin copied to clipboard
fermyon
Outbound Requests don't automatically set the `Content-Length` header
It's fairly common practice to automatically set the Content-Length header on behalf of the user. We should be doing this for outbound requests where the size of the request is known.
We should maybe only add it automatically when the known content length is non-zero; there are some cases when servers are supposed to not send it (notably 204 No Content).
https://www.rfc-editor.org/rfc/rfc9110#field.content-length
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.
A server MAY send a Content-Length header field in a 304 (Not Modified) response to a conditional GET request (Section 15.4.5); 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 200 (OK) response to the same request.
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server MUST NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 9.3.6).
But also, in agreement with this issue:
Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server SHOULD send a Content-Length header field when the content size is known prior to sending the complete header section.
Based on the results from https://github.com/fermyon/spin/pull/2249 it seems like the action items here would be to add this feature to various Spin SDKs, correct?
@vdice that is correct but as the SDKs do not live within Spin anymore, this issue is not relevant here(?)
One could imagine making this a tracking issue so that there is a central place that captures the issue for all SDKs instead of only independently tracking the issue across all SDKs.