Is it correct to response to HEAD req from elastic API with empty "transfer-encoding: chunked"?

Elastic Stack Elasticsearch
1

Hello, we're troubleshooting issue in communication between client and elastic 8.13 in between with HAProxy.
Is it correct to response to HEAD request with EMPTY "transfer-encoding: chunked"? In other words - to HEAD request to elastic API, the response is "transfer-encoding: chunked" without any data.

Thanks
Jiri

2

Yes, this is correct behaviour. See e.g. RFC 9110 §9.3.2:

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.

3

That's fine but there with NO DATA - RFC 9112 RFC 9112 - HTTP/1.1

The chunked transfer coding wraps content in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields.

And it does not have size indicator because it has no data.

4

No, that's not the case. HEAD requests are special in this regard. See e.g. RFC 9112 §6.3:

  1. Any response to a HEAD request [...] is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, [...]
5

Isn't it the same issue as it was here?

github issue

6

No, that issue was a bug, long-since fixed. IIRC we fixed it before it had any real-world impact.

7

Also from §6.1 of RFC9112

Transfer-Encoding MAY be sent in a response to a HEAD request or in a 304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer coding to the message body if the request had been an unconditional GET. This indication is not required, however, because any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.

That seems to cover exactly this scenario (please correct me if I've misunderstood the question) and the ES behaviour is explicitly allowed (though not required).

1 Like
8

Thanks Tim, that's a good quote too, although it's only a MAY ...

... whereas RFC 9110 §9.3.2 says its a SHOULD.