4

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?

Jojo
  • 643
  • 10
  • 26
  • except for content lengths wherein the value is -1; or in my case (using sockets) content length is not available in the received header. – Jojo Apr 17 '10 at 08:34
  • 1
    Is the data compressed any being decoded automatically? What are the headers? – Marc Gravell Apr 17 '10 at 08:34
  • Hi Marc, the scenario would be like this: 1. Request a file to download. The HTTP header contains a content length of 1000. 2. The file is downloaded. The actual File.Length == 1005. Is this scenario possible? I just want confirmation. I'm dealing with pdf files. – Jojo Apr 17 '10 at 08:42
  • What functions are you using to download? This pattern has been observed before. Need more info about how you are downloading it. – Nayan Apr 17 '10 at 08:49
  • using C# sockets. Socket.Recieve() function – Jojo Apr 17 '10 at 08:51
  • The class you use to write the file matters. If this is a .pdf document then make sure you use a FileStream. Using a StreamWriter will destroy the file content as it tries to convert the bytes to text. Use WebClient.DownloadFile instead. – Hans Passant Apr 17 '10 at 12:11

3 Answers3

1

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
  • 106,783
  • 21
  • 203
  • 265
  • So is it possible that the actual downloaded file length does not equal to the content-length header? – Jojo Apr 17 '10 at 08:55
  • @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 Apr 17 '10 at 10:22
  • 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 Apr 19 '10 at 02:09
  • @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 Apr 19 '10 at 07:28
0

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
  • 40,156
  • 8
  • 95
  • 98
  • 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 Apr 17 '10 at 09:35
  • 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 Apr 17 '10 at 11:39
-1

You can use WebClient.DownloadTaskAsync(...) instead. There file size will be the same.

piman314
  • 5,285
  • 23
  • 35
Java_Dude
  • 97
  • 9