© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
FWIW, the RFCs are pretty clear[0][1] that *no* HEAD responses may have a body, even if there's a 'Transfer-Encoding: chunked' header in the response:
> 1.Any response message which "MUST NOT" include a message-body (such
> as the 1xx, 204, and 304 responses and any response to a HEAD
> request) is always terminated by the first empty line after the
> header fields, regardless of the entity-header fields present in
> the message.
What's your proxy pipeline look like? I know I've managed to get some strange behaviors with quick-n-dirty custom middlewares before. I happen to have one handy that wraps the app_iter in a generator and lets me get a similar error when talking to an object-server:
vagrant@
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 6030 (#0)
> HEAD /sdb3/996/
> Host: 127.0.0.1:6030
> User-Agent: curl/7.58.0
> Accept: */*
> X-Backend-
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Date: Sat, 14 Dec 2019 02:22:04 GMT
< Transfer-Encoding: chunked
<
* Excess found in a non pipelined read: excess = 5 url = /sdb3/996/
* Connection #0 to host 127.0.0.1 left intact
(Excess is five for b"0\r\n\r\n".) It doesn't work against the proxy for me, though:
vagrant@
* Trying 10.0.2.15...
* TCP_NODELAY set
* Connected to saio (10.0.2.15) port 8090 (#0)
> HEAD /v1/AUTH_
> Host: saio:8090
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Content-Length: 0
< Transfer-Encoding: chunked
< X-Trans-Id: txa18c02d377784
< X-Openstack-
< Date: Sat, 14 Dec 2019 02:22:27 GMT
<
* Connection #0 to host saio left intact
I guess the 'Content-Length: 0' saves us somehow? Anyway, kinda smells like an eventlet bug to me... it definitely shouldn't be sending any body in response to a HEAD, even if the application provides one.
[0] https:/
[1] https:/