Correctly handle responses to HEAD requests that use Content-Length

[zenhack]

Previously, if the bridge saw a Content-Length header, but the length of
the body did not match, it would throw an error. However, for HEAD
requests this is incorrect, so with this patch the check only applies to
non-HEAD requests; for HEAD requests we will expect an empty body.

This also changes WebSessionBridge to ignore the body of HEAD requests

Fixes #3454

---

@rs22, want to test?

[rs22]

Thanks a lot! This solves my problem 🚀

I noticed that the Content-Length header in HEAD responses still is not passed on to the requesting client by Sandstorm. This is no problem in my particular case, but other applications might depend on this?

The RFC says that it's optional:

A server MAY send a Content-Length header field in a response to a HEAD request

from https://tools.ietf.org/html/rfc7230#section-3.3.2

The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields MAY be omitted.

from https://tools.ietf.org/html/rfc7231#section-4.3.2

[zenhack]

Yeah, that's a bit fiddly to do since right now the WebSession API infers the Content-Length from the actual size of the body -- I think it would work to use the streaming api and just call expectSize() without actually writing the data afterwards, but that's a bit gross because the docs for ByteStream suggest that that should be considered an error... probably a "cleaner" solution would be to tweak the interfaces somehow, but I'm inclined to say that should probably be a follow-on issue then.

[kentonv]

I think the changes to web-session-bridge.c++ are redundant as KJ's HTTP implementation will already ignore the body for a HEAD request. If so can we revert that part?

[zenhack]

I think the changes to web-session-bridge.c++ are redundant as KJ's HTTP implementation will already ignore the body for a HEAD request. If so can we revert that part?

Looks like you're right, done.