31

Is it possible to set the content-length header and also use chunked transfer encoding? and does doing so solve the problem of not knowing the length of the response at the client side when using chunked?

the scenario I'm thinking about is when you have a large file to transfer and there's no problem in determining its size, but it's too large to be buffered completely. (If you're not using chunked, then the whole response must get buffered first? Right??)

thanks.

p00ya00
  • 746
  • 1
  • 10
  • 20

4 Answers4

37
  1. No:

"Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored." (RFC 2616, Section 4.4)

  1. And no, you can use Content-Length and stream; the protocol doesn't constrain how your implementation works.
shA.t
  • 15,880
  • 5
  • 49
  • 104
Julian Reschke
  • 37,619
  • 8
  • 86
  • 92
  • I hope chunked transfer encoding is an example for stream; you have mentioned here ins't it? it may also include range requests. am i right? – Jayapal Chandran Sep 01 '11 at 00:10
12

Well, you can always send a header stating the size of the file. Something like response.addHeader("File-Size","size of the file");
And ignore the Content-Length header.

The client implementation has to be tweaked to read this value, but hey you can achieve both the things you want :)

Gyan
  • 1,156
  • 1
  • 12
  • 26
  • 8
    The convention is to use an `X-` prefix on any nonstandard header. A HTTP proxy may well decide to drop your non-standard non-X header. – MSalters Apr 06 '17 at 08:47
  • Thanks MSalters, just got referenced to a similar guideline elsewhere, appreciate it. – Gyan Apr 06 '17 at 11:33
  • 5
    As of 5 years ago, the `X-` prefix on nonstandard headers is frowned upon, deprecated, and not considered a best practice. Just go ahead and use `file-size` as the header name, it's fine. https://tools.ietf.org/html/rfc6648 – isaacs Sep 14 '17 at 02:26
0

You have to use either Content-Length or chunking, but not both.

If you know the length in advance, you can use Content-Length instead of chunking even if you generate the content on the fly and never have it all at once in your buffer.

However, you should not do that if the data is really large because a proxy might not be able to handle it. For large data, chunking is safer.

Bruce
  • 373
  • 2
  • 6
  • 3
    Unfortunately not helpful if you need to download a large file with progress information. – Gringo Suave Aug 16 '18 at 18:19
  • 4
    The spec only says Content-Length is to be ignored if Transfer-Encoding is present, it doesn't say you can't send it, Base on experimenting with chrome, chrome will treat Content-Length as a hint if present, and display a progress bar for file downloads. If I send an incorrect content length that is too small it displays the progress bar until the download exceeds the indicated length then switches to the streaming progress bar, and still completes the download correctly. – Glen Fletcher Oct 16 '19 at 06:19
  • This also worked when I set the Content-Length to be too large, the download stoped as per the rules for Chunking. Based on this I would use chunking for large files and set the Content-Length anyway, the only case it may be a problem is if the client is not standard compliant and give Content-Length precedences over Transfer-Encoding, hence I assume it shouldn't be a problem with any major web browsers (base on usage statistics) IE may be a problem but from memory its only about 2% of web users these days so I don't care about it. – Glen Fletcher Oct 16 '19 at 06:28
0

This headers can be cause of Postman Parse Error:

"Content-Length" and "Transfer-Encoding" can't be present in the response headers together.

Using parametrized ResponseEntity<?> except raw ResponseEntity in controller can fixed the issue.

shA.t
  • 15,880
  • 5
  • 49
  • 104
antony-k
  • 1
  • 1