Open Warpten opened 2 years ago
Hello @Warpten, thanks for taking the time to report this twice - first on Slack, then here.
I've fixed the issue both in my version 4 work-in-SLOW-progress working copy and in a backport PR for version 3.
EmbedIO should probably forbid operating on Response.OutputStream altogether from a HEAD request
Interesting topic for a discussion 😉 (that can be later converted to a feature request).
Describe the bug Content-Length being set through either of the following ways does not reflect on the response seen on the wire when executed from the handler of an HTTP HEAD request.
To Reproduce Steps to reproduce the behavior:
Compile the following program:
HEAD
request tohttp://localhost:8080/hello/world
and notice that theContent-Length
header in response is 0.HttpListenerMode.Microsoft
.Expected behavior
Content-Length
should have the value assigned to itScreenshots![](https://cdn.discordapp.com/attachments/375009396872183808/983470318884638750/unknown.png)
Desktop (please complete the following information):
Additional context EmbedIO's built in default logger will correctly show the Content-Length in the log, but the value sent is wrong.
Something else to consider is that while calling SetLength on the response output stream throws an error (caught by EmbedIO), the value sent on the wire for Content-Length becomes correct. My guess is that it's a side-effect of the exception being thrown (which is expected).
Furthermore, EmbedIO should probably forbid operating on Response.OutputStream altogether from a HEAD request, since clients are expected to ignore the body of HEAD replies.