Transfer-Encoding: gzip

[bagder]

Is hyper doing anything special or assuming something special when Transfer-Encoding: gzip is used?

I'm trying to make curl test 1122 to work, and in this I make hyper include the following two request headers:

Connection: TE
TE: gzip

... and then it gets a transfer-encoded response back, saying Content-Length: 44 and then a gzip compressed body which happens to be exactly 44 bytes but it appears to me that hyper then doesn't consider that the end of the transfer.

Can you just clarify if this is known to be working fine with hyper?

[seanmonstar]

I just looked through the source code, and confirmed it is setting the body to "close-delimited". This is based on what it says in RFC 7230 $3.3.3 :

If a Transfer-Encoding header field is present in a response and the chunked transfer coding is not the final encoding, the message body length is determined by reading the connection until it is closed by the server.

If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length.

[bagder]

Then of course, using transfer-encoding for anything but chunked is very rarely used. And never by browsers for example.

[bagder]

But I will agree that the RFC says what you're saying. Maybe I should take this to some HTTP peeps.

[bagder]

... the reason for this is that the Content-Length is the size of the compressed data, which means that when the transfer decoding changes the size, the amount may/will differ from the given size in the header.

Also detailed in the Content-Length section.

[bagder]

I could perhaps add that when I added transfer-encoding support to curl, lots of years ago, the (live) server end we used provided content-lengths the way curl now supports. Now I need to ponder on how to proceed from here.

Thanks a lot @seanmonstar for your quick answers.

[bagder]

FYI: the next step went here: curl/curl#7643