37

The client is making a range request 0-1023 to the http server. It prefers gzip compression with Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 in the request.

What would be the content-length in the response header? Will it be 1024 or the size of the compressed data.

Thanks,

Mir-Ismaili
  • 13,974
  • 8
  • 82
  • 100
derekwei
  • 473
  • 1
  • 6
  • 10

4 Answers4

26

It depends on the Content-Encoding.

RFC 2616 has this to say (amongst other things) about Content-Length:

Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.

So we have to figure out what transfer-length is; Section 4.4 (Message Length) says these two things about transfer-length:

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied.

If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different

Okay, so we know that in this case transfer-length, entity-length, and Content-Length all have the same value, and all refer to "the length of the message-body as it appears in the message", and so we have to determine what message-body is. Section 4.3 says this about message-body:

The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response."

So what's an entity-body? For that you have to refer to basically all of Section 7. (Which also defines entity-length.) Most importantly, there this:

entity-body := Content-Encoding( Content-Type( data ) )

The length of the entity-body (and therefore our value for Content-Length per 4.4) is the length of the data after content-coding.

user3840170
  • 26,597
  • 4
  • 30
  • 62
pkh
  • 3,639
  • 1
  • 23
  • 18
  • 3
    Wrong. We're discussing Content-Encoding, not Transfer-Encoding. It will be the first 1024 bytes of the content *after* gzip compression. – Julian Reschke Sep 10 '13 at 06:12
  • 2
    Your "Wrong." is incorrect. I'll accept "Not quite complete." I've added the rest of the trail through to Content-Encoding. – pkh Sep 10 '13 at 18:39
  • 3
    It's still incorrect. If you ask for 1024 bytes of a resource with Content-Encoding: gzip, it's 1024 bytes (of the gzipped) resource that you'll get. – Julian Reschke Sep 10 '13 at 20:50
  • 1
    Ah. Fair point -- I didn't closely read the question today and three years ago probably didn't know what he meant by "range request." Which means that we're both wrong. It's going to be the smaller of 1024 or the compressed size. – pkh Sep 10 '13 at 23:15
  • 37
    I find this answer a big ambiguous. Is it the **length of the gzipped data** OR is it the **length of the data before gzipping**? – CMCDragonkai Apr 26 '15 at 06:58
  • I opened nu.nl and checked the files transfered. It seems to be the length of the gzipped data (without all the HTTP headers of the response). – Jorrick Sleijster Jan 19 '23 at 10:37
2

The actual content length depends on the transfer encoding and data: If you use identity, no compression is applied and the content length is 1024; if you use gzip, the actual content length depends on the data that is to be compressed.

Gumbo
  • 643,351
  • 109
  • 780
  • 844
0

Actually it will be 1024 which is the size of compressed data.

Ali
  • 21,572
  • 15
  • 83
  • 95
0

The purpose of Content-Length response headers is to allow the client to know the precisely how many bytes to read until it has the entire response. Hence the length must be the compressed one (what the browser will receive from the socket before decompression).

Marcelo Pacheco
  • 152
  • 1
  • 5