tags:

views:

63

answers:

2

Does anyone has any experience wherein the requested file to download (HTTP) content length in the header does not equal to the actual file length (size) when downloaded?

+1  A: 

The content length header is the number of bytes in the body of the HTTP response.

This is calculated after all encoding stages, most encoding methods will change the length.

  • Compression will shrink it
  • Base 64 will increase it.

The content length header is only useful in terms of how much raw data to read from the socket. It will not help will allocating a buffer to hold the decoded content.

(I have just written some code to pull data down, but have to read the response stream incrementally expanding the buffer rather than one big allocate an read.)

Richard
So is it possible that the actual downloaded file length does not equal to the content-length header?
Jojo
Base64 is not used in HTTP.
Julian Reschke
@Jojo: correct.
Richard
@Julian: Correct, but HTTP could be used to transfer (with compression) data previously encoded with Base64. And I wanted a case of not every encoding makes things smaller as the point here is that content-length has no simple relationship with the actual size of the transferred entity.
Richard
Richard, I have not yet encountered that content-length header is not equal to the actual file size downloaded. That is why I am asking if there's a possibility that there might be instances wherein they are not equal.
Jojo
@Jojo: I have, when handling compressed content. The content-length header is the length of the compressed content, if you stream through a decompresser the final result is larger.
Richard
A: 

The way you phrase the question is misleading.

When an HTTP response carries a content-length header, that is the length of the message. Period. Well, except for HEAD responses.

If a server sends more than that, it's broken.

Julian Reschke
So if that is the length of the "message" (the "message" here might be a PDF file). Is it possible that the content-length value based on the HTTP header will not be EQUAL TO the file size of that PDF file if it is downloaded (the local file size, or the FileInfo.Length)?
Jojo
If the file I sent with a Content-Encoding (such as gzip), then the Content-Length will refer to the *compressed* size. If the recipient, such as a browser, automatically uncompresses, then yes, the resulting file will (most of the times) be bigger. Maybe you should elaborate why you're asking...
Julian Reschke