zotonic / webzmachine

Zotonic's fork of Basho's webmachine

Zotonic

Zotonic is the open source, high speed, real-time web framework and content management system, built with Erlang.

It is flexible, extensible and designed from the ground up to support dynamic, interactive websites and mobile solutions.

Zotonic is incredibly fast and wonderfully stable – suited for anything from basic websites to complex distributed applications. It offers an elegant backend for managing content with the flexibility that developers need to build truly amazing applications.

Installation

• Download Zotonic from the official website or start Zotonic from a Docker image.
• Read the Installation chapter in the documentation.

Documentation

You can find out more about Zotonic on http://zotonic.com, including:

• Official documentation.
• Release notes.

Contributing

Zotonic is an open source project, made possible by the community. If you’d like to contribute, please read the Contributing chapter in the documentation.

If you encounter any issues, please report them in our issue tracker. If you discover any security-related issues, please contact us at [email protected].

License

Zotonic is released under the Apache 2.0 License. Please refer to the included LICENSE file for more information.

Thanks

Thanks to the following services for supporting Open Source:

webzmachine's Issues

Disentangle Content-Encoding, Transfer-Encoding, character set conversion and chunked transfers.

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:

• encodings_provided/2

Change return format of:

• charsets_provided/2

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)

Replace mochiweb with elli

See also: zotonic/zotonic#533

Handling of {error, closed} missing in recv_unchunked_body

10:31:24.416 [error] webmachine error: path="/postback": {error,{error,{badmatch,{error,closed}},[{webmachine_request,recv_unchunked_body,3,[{file,"src/webmachine_request.erl"},{line,524}]},{webmachine_request,do_recv_body,1,[{file,"src/webmachine_request.erl"},{line,488}]},{webmachine_request,req_body,2,[{file,"src/webmachine_request.erl"},{line,736}]},{wrq,req_body,1,[{file,"src/wrq.erl"},{line,135}]},{controller_postback,process_post_ubf,2,[{file,"modules/mod_base/controllers/controller_postback.erl"},{line,60}]},{webmachine_controller,controller_call,3,[{file,"src/webmachine_controller.erl"},{line,209}]},{webmachine_decision_core,decision,3,[{file,"src/webmachine_decision_core.erl"},{line,484}]},{webmachine_decision_core,handle_request,2,[{file,"src/webmachine_decision_core.erl"},{line,31}]}]}}

Rename modules to prevent name clash with Basho

Our webzmachine modules are still called webmachine_...

This might give a name clash with Basho's webmachine when they are in the same vm.

I propose to rename our modules to wzm_...

Error documents should only be used when text/html is accepted

We now send a HTML error document, even when the content type of the controller will be something different.

We also don't check what the user agent accepts.

Maybe it is possible to determine the probable content type by calling content_types_provided and check it against the accept headers.

That is just like steps v3c3 and v3c4 in the webmachine_decision_core.erl

doc

do you have any doc somewhere documenting changes? how is Orking the websocket handling? ( i assume your wm could be used alone)

R17 compilation issue with dict() type

In R17 the dict() type is removed and replaced with dict:dict().

See also zotonic/zotonic#764