http server: don't automatically add a content-length header#137
Conversation
This behavior might not work on some wasi-http runtimes, since restricted headers are not specified. In particular, content-length is a header that is http1 specific - in http2 and 3 framing is handled differently. But even in http1, its making a decision about framing that the imported http implementation may not agree with, e.g. there could be an implementation that insists on always sending chunked transfer encoding, and by setting content-length all the time it means that either wstd will always unwrap on a `forbidden` error here, or the implementation has to silently filter out that header. Neither of those alternatives serve wstd's users well.
|
I missed that. Sorry, I am not familiar with jco's http.ts, but just looking at that, its obviously incorrect. It was never guaranteed that wstd would produce a content-length, it was only a possibility when wstd returned a Body impl that gave a size hint, e.g. http_body_util::Full. Its still possible for a wstd user to provide a Content-Length header corresponding to their body, this just changes wstd to not provide it for them automatically so its opt-in now, and not impossible to opt out. (And, again, just in the case of the outgoing response, the outgoing request was always missing this behavior.) Its always been important to wasi-http to support both complete and streaming bodies, otherwise we wouldn't have bothered with the massive machinery to make streaming possible. Streaming bodies necessarily cannot provide a Content-Length. if neither jco http.ts nor the test suite currently have coverage for streaming bodies, thats a pretty big problem to fix but not something I want to consider in scope to land this change. |
2 participants
This behavior might not work on some wasi-http runtimes, since restricted headers are not specified.
In particular, content-length is a header that is http1 specific - in http2 and 3 framing is handled differently. But even in http1, its making a decision about framing that the imported http implementation may not agree with, e.g. there could be an implementation that insists on always sending chunked transfer encoding, and by setting content-length all the time it means that either wstd will always unwrap on a
forbiddenerror here, or the implementation has to silently filter out that header. Neither of those alternatives serve wstd's users well.