-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content-Length is removed by OkHttp but getContentLength returns -1 #259
Comments
A few questions:
|
|
from my test, when Test code:
|
OkHttp only strips the content length if it's doing transparent gzip. It's possible your webserver isn't sending a content length. |
you are right. the url doesn't return a Content-Length. sorry for the false bug report. |
Do you mind explaining why? |
There's two lengths:
When we strip the content length from the HTTP response, it's because we know c but the application developer is expecting o. (And will receive o bytes when they consume the entire stream.) |
@swankjesse we want content length over the wire. I didn't find a way to unzip the response manually to support not getting the content length header stripped. |
We want c for other reasons. I think I was able to get it by reading the Content-Length header inside of a NetworkInterceptor. Diminishing returns in our case, so I hope it's correct. We wanted c but o will tell us almost as much and be hard to distinguish during our early collection phase. |
Yep. Reading it in a network interceptor is the way to go. Alternately you can do gzip yourself; that’s just another interceptor to make. |
@samtstern |
@arnavzoman thanks for the heads up! I don't completely understand the issue here (I don't work on Firebase Perf directly), would you mind filing an issue on |
Cool, I have done that |
swankjesse@ Thanks for explanation. I have a couple of questions: Q1: Do we discard original content-length because we only know about compressed content (which is not what the caller is expecting) at that point? Q2: Does reading from the NetworkInterceptor provides Original content length of Compressed content length? Q2.1: If Original, then is it possible for OkHttp to provide the original content length by adding the Network Interceptor themselves rather the caller implementing it? Q2.2: If Compressed, then is there any other way caller can get the Original content length? or the caller has to read the entire stream to get that answer? |
@swankjesse Would be great if you can check out #259 (comment) once. |
Note that the original network response headers are available:
|
Thanks @swankjesse Is there also a way to get the compressed content length info (so basically the actual wire download size)? |
You could get it from the EventListener. Or create a
|
Reading the stream of data may be the last thing we would do. But thanks for highlighting that well. Can you provide example with EventListener? |
Install an EventListener, and override this method: |
The web server does return a positive "Content-Length" header (as checked in debug mode and also separated test) but OkHttp removed it so the header cannot be retrieved by getHeaderFields. I guess the removal is intended as there is a getContentLength method to retrieve the content length. However, in my case, the content length is -1.
The web server supports gzip/inflat, and the problem occurs when "Accept-Encoding" is not set (also when "Accept-Encoding" is set to "identity", as i tried after seeing #116). When "Accept-Encoding" is set to "gzip,deflate", content length is normal/positive. So i suppose the problem is caused by a transparent/automatic gzip is happening.
I suppose I shouldn't set "Accept-Encoding" to gzip, because when I connect to a server that doesn't support zip, my code can't tell whether the input stream is gzip'd or not, right?
btw, I need to get the content length either from the API or from HTTP Header for change detection.
The following issues are similar but apparently different issue.
#116
#250
The text was updated successfully, but these errors were encountered: