Http static file, compression and range header : non conformant implementation ?
I have made some experiments with a simple GET /staticfile.txt,
Trials have been done with GF 3.1.2, compression is set to "forced"
Http request headers :
Response headers (extract) :
Content-Range: bytes 10-20/13244
Default servlet extract the 11 bytes from the file, and compress them.
If I gunzip the returned bytes, I get back the (11 bytes length) slice
of my file.
However, this is probably not the "usual" behaviour :
in this case, it seems that the correct implementation
would be to first gzip the whole file, then return bytes
10-20 from the gzipped data.
Here what apache 2.2.22 returns (although apache is
not the reference implementation on that point) :
Content-Range: bytes 10-20/120
Note the total content length (120), way smaller than my file length.
The 11 bytes can not be decoded by gunzip, as they are in the middle
of the gzip stream.
From what I have understood of http/1.1, this way of gzipping the range
would be conformant if I used the transfer encoding headers :
TE: gzip, chunked
and if server answered with the following header :
Transfer-Encoding: gzip, chunked
Here are some relevant links :
It appears that the Transfer-Encoding support is very poor
in standard browsers (and I am afraid also for http proxys).
But the GF3 response will probably confuse a conformant
Thank you for your attention,