[erlang-questions] Handling non http in mochiweb

Magnus Klaar magnus.klaar@REDACTED
Thu Aug 18 18:23:03 CEST 2011

On Thu, Aug 18, 2011 at 5:54 PM, Bob Ippolito <bob@REDACTED> wrote:

> On Thu, Aug 18, 2011 at 8:48 AM, Magnus Klaar <magnus.klaar@REDACTED>
> wrote:
> > 2011/8/18 ori brost <oribrost@REDACTED>
> >>
> >> I will describe my exact problem, maybe there are other solutions i
> >> did not think of.
> >> Our program provides a websocket service over a port. We wish to allow
> >> people without a websocket supporting browser to use it so we use a
> >> flash object to do websocket when the browser can't. In order for this
> >> to work, the flash object needs to get a flash policy file. Flash
> >> forces the file to be in one of two places:
> >> - port 843 (flash hard coded)
> >> - the port of the ws service
> >> Note that the flash protocol is NOT HTTP based.
> >> Originally we worked with 843, but we then decided to put out server
> >> behind an Amazon ELB. Amazon ELB does not allow port forwarding for
> >> ports below 1024 which are not 80 or 443, so our only choice was to
> >> implement the flash policy file server in the same port via a patch to
> >> mochiweb (https://github.com/nivertech/mochiweb/tree/ori_flash_170811).
> >> We also thought of putting the websocket service behind an haproxy
> >> instead of ELB, but ELB is better because it is also hardware based
> >> unlike haproxy which is only software.
> >>
> >> Do you see any other solution for this?
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >
> > Hi!
> > This is a shameless plug for cowboy, putting this aside, I think it you
> > would end up with a solution similar to this if you were to patch
> mochiweb
> > suit this usecase.
> > I wrote a blog post on getting started using cowboy for non-http
> protocols
> > yesterday because of a question on IRC wrt. to finding a reusable
> > acceptor/handler pool for connection oriented servers. You will find it
> > here:
> http://mklaar.posterous.com/accepting-and-handling-tcp-connections-with-c
> > Now, you would be able to write a protocol module such as
> > flash_policy_or_http_protocol that read N bytes from the socket, if they
> > match an HTTP method, you can call the cowboy_http_protocol:init/4 and
> > handle it as an HTTP request. If they match what you expect to find at
> the
> > head of a flash policy request you can call flash_policy_protocol:init/4.
> > The only change I anticipate that you would have to make to cowboy itself
> > would be to add an option for injecting an intial buffer into the
> > cowboy_http_protocol state to ensure that erlang_decode:packet doesn't
> start
> > reading in the middle of the input.
> > (I failed at the internet, I'm sorry if you receive duplicates of this
> > email)
> FWIW, mochiweb also has a reusable acceptor/handler pool
> implementation with an unsurprising name: mochiweb_socket_server.
> mochiweb_http is just a handler that sits on top of this facility.
> In either case, if you need to stuff something back onto the socket
> buffer, there's an undocumented gen_tcp:unrecv/2 that would work if
> you can't find an elegant and supported way to do it.
> -bob


Nice, that solves this problem then. I only took a quick look at
mochiweb_socket_server and mochiweb_http, but it looks like there is nothing
stopping you from using the same module structure as I suggested earlier.
Replace Protocol:init/2 in my post with Protocol:loop/2 and you're done.

Making changes to either one of the flash_policy or mochiweb-http module
will land you with at least one module that is "bloated" or hard to reuse.

MVH Magnus Klaar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110818/fd898c40/attachment.htm>

More information about the erlang-questions mailing list