In Webmachine there is a bit confusion between Content-Encoding and Transfer-Encoding.
The Content-Encoding is applied by functions, though also on the chunks. This doesn't play well with gzip, as that should be applied to the whole entity and not to its chunks.
The idea behind Content-Encoding is that the server has multiple versions of an entity, and can select which version should be served. That means that the server has already a prepared compressed version of the data. The Range is also applied on this (compressed) version of the data.
The Transfer-Encoding is applied after the fetching the correct ranges and can consists of chunking or (further) compression. There can be multiple Transfer-Encodings, they are given in the header in the order that they were applied. For example, first chunking and then gzip will give:
Transfer-Encoding: chunked, gzip
This plays well with different content encodings.
In this way there will be a clear distinction: the controller provides the content and Webzmachine might add transfer encodings.
On a similar note, the character set is almost always UTF-8 and should be supplied by the content, i.e. not changed by Webzmachine.
I propose to add two new callbacks, remove one, and change another:
New:
- content_encodings_provided/2
- transfer_encodings_provided/2
Remove:
Change return format of:
All three will return a list of encodings/charsets, instead of tuples with the encoding and re-code functions.
The content_types_provided/2 function should then take the selected charset and encoding to select the correct content function (or the content function can handle that).
The selected encodings are available from:
webmachine_request:get_metadata('content-encoding', ReqData)webmachine_request:get_metadata('chosen-charset', ReqData)webmachine_request:get_metadata('content-type', ReqData)
In Webmachine there is a bit confusion between
Content-EncodingandTransfer-Encoding.The
Content-Encodingis applied by functions, though also on the chunks. This doesn't play well with gzip, as that should be applied to the whole entity and not to its chunks.The idea behind
Content-Encodingis that the server has multiple versions of an entity, and can select which version should be served. That means that the server has already a prepared compressed version of the data. TheRangeis also applied on this (compressed) version of the data.The
Transfer-Encodingis applied after the fetching the correct ranges and can consists of chunking or (further) compression. There can be multiple Transfer-Encodings, they are given in the header in the order that they were applied. For example, first chunking and then gzip will give:This plays well with different content encodings.
In this way there will be a clear distinction: the controller provides the content and Webzmachine might add transfer encodings.
On a similar note, the character set is almost always UTF-8 and should be supplied by the content, i.e. not changed by Webzmachine.
I propose to add two new callbacks, remove one, and change another:
New:
Remove:
Change return format of:
All three will return a list of encodings/charsets, instead of tuples with the encoding and re-code functions.
The content_types_provided/2 function should then take the selected charset and encoding to select the correct content function (or the content function can handle that).
The selected encodings are available from:
webmachine_request:get_metadata('content-encoding', ReqData)webmachine_request:get_metadata('chosen-charset', ReqData)webmachine_request:get_metadata('content-type', ReqData)