-
Notifications
You must be signed in to change notification settings - Fork 176
Partial content and compression
As of version 3, FileModule
supports the delivery of partial content, i.e. requests containing a Range
header are correctly handled.
EmbedIO also supports both gzip
and deflate
compression when requested through Content-Encoding
headers.
The combination of the two, however, is not supported. When a request contains both Range
and Content-Encoding
headers, the following will happen:
- If the client can accept an uncompressed response payload (e.g. the
Content-Encoding
header also containsidentity
), then theRange
header is honored: the resulting uncompressed response will contain the requested range. - If the client cannot accept an uncompressed response payload, then the
Range
header is ignored: the response will contain the whole requested resource, compressed with the requestedContent-Encoding
method.
You can verify this behavior by looking at the source for FileModule
.
There's an interesting discussion on the subject on ruby-forum.com. It's a few years old, talking about Nginx vs. Apache and CURL vs. browsers, but the relevant parts of RFCs have not changed much in the meantime.
In short, combining range requests with content compression would mean sending pieces of a gzipped / deflated resource. The client couldn't decompress the resource without first combining all the pieces, because of how compression / decompression algorithms work. Different clients will mess things up in different ways; there seems to be no clear standard about handling compressed 206 Partial Content
responses. Therefore it makes no sense to send them.
This is usually no big deal, since most files over a few kilobytes are compressed anyway: think ZIP, JPEG, PNG, even OfficeOpenXML and OpenDocument (which are ZIP files under disguise).