ContentLength equals zero with response body

[Ne0nd0g]

I'm currently trying to use v0.14.4 of quic-go. When a HTTP3 response is returned, the ContentLength is set to zero but the response body has valid data. I'm getting an error later while processing the response body because the ContentLength is 0. I was previously using v0.10.2 without error and mostly just upgraded library version in my go.mod file without really changing the code base. I was expecting for the ContentLength to be anything except for zero (i.e -1 or 6016). The response body is a gob encoded JWE object. KeepAlive is set to false in the quic config for both the server and the client. The reqDoneClose field is set to true so I'm assuming the connection is done. I'm not really sure how to troubleshoot more and any help would be appreciated.

Example of debug output from the response:

[DEBUG]HTTP Response:
&{Status:200 OK StatusCode:200 Proto:HTTP/3 ProtoMajor:3 ProtoMinor:0 Header:map[Content-Type:[application/octet-stream]] Body:0xc000410040 ContentLength:0 TransferEncoding:[] Close:false Uncompressed:false Trailer:map[] Request:<nil> TLS:<nil>}
[DEBUG]ContentLength: 0
[DEBUG]Body: &{str:0xc0001961e0 isRequest:false reqDone:0xc00002e360 reqDoneClosed:true onFrameError:0x914e30 bytesRemainingInFrame:0}
[DEBUG]Body Length(read): 6016

[marten-seemann]

Looks we still have similar code for determining the value as we had in v0.10.2:
https://github.com/lucas-clemente/quic-go/blob/ce64c6b301e78ee3a26789c5da49174b89c2c9ef/http3/request_writer.go#L65-L72

I don't the time to debug this now, but the code above should be a good starting point for debugging. A PR with a fix would be very much appreciated!

[marten-seemann]

Here's what a quick search in the standard library HTTP/2 code revealed:

The server tries to determine the Content Length: https://github.com/golang/net/blob/4c5254603344ea4a8ae4bed7e296a9588303e14f/http2/server.go#L2021-L2030
The client
When reading the HTTP response, it looks like the client set the Content Length to -1, unless it is set in the request: https://github.com/golang/net/blob/4c5254603344ea4a8ae4bed7e296a9588303e14f/http2/transport.go#L2007-L2018

quic-go currently does neither of those two things..

[awrenn]

Hi - has this issue been fixed? I was poking around at it today just to learn more about this library.

It looks like some of the information in these threads is a little out of date, so I'll just try and re-clarify some things...
It looks like the issue can be solved with a little logic in:
https://github.com/lucas-clemente/quic-go/blob/bfad41165cfb41fd9f60e21d5937777ae332900f/http3/client.go#L322-L330

Content Type is only being placed into the response object if some compression options are set, and then it is only ever set to -1.

If I add some logic here to parse the header in the common case and set to -1 if header missing or un-parsable, then things seem right to the calling client.

Please let me know if I'm missing anything - but it seems like this issue is only a couple lines away from being solved if it hasn't been already.