Skip to main content

Http static file, compression and range header : non conformant implementation ?

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
2 replies [Last post]
momaison
Offline
Joined: 2008-09-29

Hello,

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 :
Accept-Encoding: gzip
Range: bytes=10-20

Response headers (extract) :
Content-Range: bytes 10-20/13244
Transfer-Encoding: chunked
Content-Encoding: gzip

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-Encoding: gzip
Content-Range: bytes 10-20/120
Content-Length: 11

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 :
http://forum.nginx.org/read.php?2,209738,209817
http://stackapps.com/questions/916/why-content-encoding-gzip-rather-than...

https://bugzilla.mozilla.org/show_bug.cgi?id=68517
https://issues.apache.org/bugzilla/show_bug.cgi?id=52860

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
http proxy.

Thank you for your attention,

M. Maison

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
seamus_mulholland
Offline
Joined: 2013-09-06

Dear Mr Maison,

I have been encountering the same problem as you have outlined. I wonder have you been able to resolve your issues?

I am making a 'Range' header request to an Apache server which has enforced GZIP compression. It seems to compress the entire file I am requesting then return the compressed data range according to the 'Range' header. This is not my desired result. I would like the 'Range' to be taken from the uncompressed data, then compressed and returned.

Any help would be gratefully received.

momaison
Offline
Joined: 2008-09-29

I've not found any solution with GlassFish (at least any
http compliant solution, as GF violates RFC in that case).

IIUC, the right way would be to use request header "TE: gzip" :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39
Unfortunately even apache it not able to handle this header
(not with default settings at least)

M.

Le 06/09/2013 20:00, forums@java.net a écrit :
> Dear Mr Maison, I have been encountering the same problem as you have
> outlined. I wonder have you been able to resolve your issues? I am
> making a
> 'Range' header request to an Apache server which has enforced GZIP
> compression. It seems to compress the entire file I am requesting then
> return
> the compressed data range according to the 'Range' header. This is not my
> desired result. I would like the 'Range' to be taken from the
> uncompressed
> data, then compressed and returned. Any help would be gratefully
> received.
>
> --
>
> [Message sent by forum member 'seamus_mulholland']
>
> View Post: http://forums.java.net/node/884349
>
>
>