Skip to content

Partial content and compression

Riccardo De Agostini edited this page Dec 9, 2019 · 1 revision

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 contains identity), then the Range 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 requested Content-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).