I'm submitting a ...

• bug report
• new feature / enhancement request
• improvement request (usability, performance, tech debt, etc.)
• other

Traffic Control components affected ...

• CDN in a Box
• Documentation
• Grove
• Traffic Control Client
• Traffic Monitor
• Traffic Ops
• Traffic Ops ORT
• Traffic Portal
• Traffic Router
• Traffic Stats
• Traffic Vault
• unknown

Current behavior:

The TR response to a HEAD request should resemble the same as a GET response. However, the behavior I'm seeing seems problematic. Following examples of each (from curl output) with timing info included:

Proper GET response:

> GET / HTTP/1.1
> Host: [REDACTED]
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Location: [REDACTED]
< Content-Length: 0
< Date: Tue, 08 Oct 2019 14:58:45 GMT
<
* Connection #0 to host [REDACTED] left intact

real	0m0.705s
user	0m0.008s
sys	0m0.015s

Improper HEAD response:

> HEAD / HTTP/1.1
> Host: [REDACTED]
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Location: [REDACTED]
< Transfer-Encoding: chunked
< Date: Tue, 08 Oct 2019 15:23:12 GMT
<
* transfer closed with outstanding read data remaining
* stopped the pause stream!
* Closing connection 0

real	0m10.855s
user	0m0.007s
sys	0m0.017s

Note that the HEAD response is including Transfer-Encoding: chunked, which is causing the client to wait for body data which never arrives. After ~10 seconds, Traffic Router times out the connection and resets the TCP connection (verified TR sends FIN at this point with a packet capture).

Expected / new behavior:

TR should be responding to a HEAD request with Content-Length: 0, and NOT Transfer-Encoding: chunked.

Minimal reproduction of the problem with instructions:

Traffic Router version: 3.0.0-9930.f225e63b.el7

Problem can easily be replicated by sending a HEAD request with curl:

time curl -vs -o /dev/null -X HEAD http://ccr.invalid.cdn.example.com/

Anything else: