Web server: replace MochiWeb #533

Closed
arjan opened this Issue Mar 14, 2013 · 18 comments

Comments

Projects
None yet
5 participants
Owner

arjan commented Mar 14, 2013

See #513 for discussion on this

mmzeeman was assigned Mar 14, 2013

arjan referenced this issue Mar 14, 2013

Closed

Remove all parametrized modules for R16 #513

2 of 2 tasks complete
Owner

mworrell commented Mar 14, 2013

mworrell referenced this issue in zotonic/webzmachine Mar 14, 2013

Open

Replace mochiweb with elli #9

Owner

mworrell commented Mar 14, 2013

The same ticket, but then on webzmachine: zotonic/webzmachine#9

Owner

mmzeeman commented Mar 14, 2013

Elli misses a couple of things we need.

  1. Https support (Made a pull request for that. No reaction so far)
  2. Support for protocol update.
  3. Support for large requests. File uploads and that sort of thing.
Owner

kaos commented Mar 14, 2013

Link to the pull request of point 1 above: knutin/elli#57.

Owner

mmzeeman commented Mar 14, 2013

I did just have an email conversation with Knut, the author of elli, about this.

His main goals is to maintain a small, high quality, http server implementation. He liked our "pass the socket to the handler" idea for upgrade and file uploads. He was thinking about adding exactly the same for doing responses.

That way allows anybody with special needs to implement it on their own keeping the core library small.

Owner

kaos commented Mar 14, 2013

Sounds good.

Owner

mworrell commented Apr 18, 2013

The SSL and socket-process support has been added to Elli (per communication by @mmzeeman)
So we can continue :-)

Owner

mmzeeman commented Oct 20, 2013

Last saturday I did some experimenting to see what it takes to use elli instead of mochiweb.

https://github.com/mmzeeman/webzmachine/blob/elli/src/webmachine_elli.erl

What I learned was that it will take quite a bit of work to replace mochiweb, but it will be well worth it.

Elli is very extensible. They do access logging, efficiently add date headers in separate extensions. This will give us a choice where to add things.

Details like adding a server header can then be removed from the webmachine core code and implemented as a small and clean extension.

Maybe we should also consider to implement long-polling and websockets as an elli extension instead of shoe horning it onto a webmachine controller. Webmachine controllers are better for REST like resources.

What do you think?

Owner

mworrell commented Feb 16, 2015

I am still leaning towards Elli. I am wondering if they will support http2 though,

Owner

mmzeeman commented Feb 16, 2015

I send out a ping to @knutin

On 16 Feb 2015, at 22:21, Marc Worrell notifications@github.com wrote:

I am still leaning towards Elli. I am wondering if they will support http2 though,


Reply to this email directly or view it on GitHub #533 (comment).

ddeboer changed the title from Web server: Replace mochiweb with elli to Web server: replace MochiWeb Jan 7, 2016

Owner

ddeboer commented Jan 7, 2016

@mworrell mailed:

We have now two wiki pages with information about replacing MochiWeb in Zotonic.

The discussion as part of our optimizations:

https://github.com/zotonic/zotonic/wiki/Improving-zotonic's-throughput#usage-of-mochiwebwebmachine-with-no-binaries

And just added, specifically about Cowboy:

https://github.com/zotonic/zotonic/wiki/Proposal-for-using-Cowboy-as-the-HTTP-server

Please check and add your comments.

Let’s do so here. 😉

Owner

mmzeeman commented Jan 7, 2016

Is this our wish list?

  • webmachine like request handling
  • comet
  • websockets
  • http2
  • sse possibility
  • file uploads
  • file downloads (chunked)
  • being able to work without hassles for corporate users with broken clients
  • ssl + sni
  • good access logging (our current log is broken for some edge cases)
  • measurability (how long do things take internally)
  • how does it handle things when process running out of sockets or when other things break?
  • debuggability
  • testability. (how easy is it to test controllers?)
Owner

mworrell commented Jan 7, 2016

And:

  • compatible (or almost...) with our current controllers
Owner

ddeboer commented Jan 12, 2016 edited

  • In our meeting today, we decided to go for Cowboy, mainly based on the fact that it is widely adopted and has a large developer community.
  • We will define a Controller behaviour that fits Zotonic well and is simpler than the current one.
  • @mworrell will start working on making all request handling asynchronous, which is also a preparation for HTTP/2.
Owner

mworrell commented Jan 12, 2016

Will also start mapping all query args to binaries, so that we can start adapting the code base.

Owner

mworrell commented Jan 13, 2016

I will send an email to the mailing lists to warn about the incompatibilities we will be introducing in master.

Owner

ddeboer commented Jul 26, 2016 edited

To help the general understanding (including my own):

HTTP request  → Cowboy             → z_sites_dispatcher
(handled by)    (calls middleware)   (returns Zotonic controller fun to Cowboy)
                                   ←
                (calls middleware) → cowmachine
                                     (returns controller response to Cowboy)
                                   ←
HTTP response ← 
(served by)

ddeboer closed this in #1355 Aug 30, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment