[erlang-questions] configure http methods in yaws

[Bogdan Andu]

Hi,

I know the docs
and I run internally Yaws in reverse proxy mode
and I want this in Internet facing setup also

I searched the net 'yaws reverse proxy' and I found:

1)
http://stackoverflow.com/questions/917546/has-anybody-used-yaws-server-as-an-http-proxy
   although 6 years  old, is Yaws in reverse proxy mode comparable or even
   better than varnis, haproxy, nginx?

2) http://osdir.com/ml/web.server.yaws.general/2007-12/msg00000.html
    this one is from klacke and he speaks about difficulties he
    encountered writing revproxy engine.as well as an OTP limitation
    being the main obstacle in overcoming these.
    Are these still apply today?

3) also found this:
http://www.erlang-factory.com/upload/presentations/752/reed-efsf2013-whatsapp.pdf
    it seems whatsapp useses or used yaws in revproxy mode with some tweaks

The setup I want is simple:

Because I have the applications written in other language
and for rewriting them in Erlang I dont have the time I must
use this setup:

 - Yaws in front-end in revproxy mode with interception module with plenty
of check
on headers, cookies, etc
 - Twiggy/Starlet/Starman as back-end or psgi server
   more info here: http://www.slideshare.net/kazeburo/yapc2013psgi-plack

 I want to keepalive connections between yaws and psgi servers to avoid
 3-way handshake overhead. Although with outside world I want disable
keepalive
  and set 'connection: close' and all of thiese can be done by altering the
headers
 tru interception module.


Is it safe to keepalive connections between Yaws and Twiggy for
example which is an Libevent implementation web server?
Or Starlet/Starman like web server which has a parallel pre-fork model?

Thanks and sorry for long post,

Bogdan




On Sun, Jun 28, 2015 at 4:51 AM, Steve Vinoski <vinoski@REDACTED> wrote:

>
>
> On Sat, Jun 27, 2015 at 4:58 AM, Bogdan Andu <bog495@REDACTED> wrote:
>
>> Hi,
>>
>> About yaws as reverse proxy..
>>
>> I want to use yaws as a reverse proxy in a
>> http -> http setup. no ssl involved whatsoever.
>>
>> I am interested in interception module where I want
>> to apply various checks on headers, query string, etc
>> making this some kind of www firewall .
>>
>> Is this feature of yaws production ready ?
>>
>
> Yes. You can find details about it in chapter 13 of
> http://yaws.hyber.org/yaws.pdf, or under the revproxy section of
> http://yaws.hyber.org/yman.yaws?page=yaws.conf .
>
> --steve
>
>
>
>>
>>
>> Thanks,
>> Bogdan
>>
>>
>> On Fri, Feb 13, 2015 at 6:14 PM, Steve Vinoski <vinoski@REDACTED> wrote:
>>
>>> I don't recall seeing Yaws users asking for this config feature in the
>>> past, so it's unlikely we'll add it. But what you're asking for -- a
>>> configuration point for methods -- would be implemented much as I've shown
>>> in my previous emails, much like a dispatchmod. The dispatchmod is as early
>>> in the request handling process as you can get after the formation of the
>>> #arg{}. The dispatchmod code I provided requires less configuration than
>>> what you're showing, even for the default case, plus if having to have a
>>> new module concerns you, the dispatch/1 function can be added to some other
>>> existing module you already have instead.
>>>
>>> --steve
>>>
>>>
>>>
>>> On Fri, Feb 13, 2015 at 4:30 AM, Bogdan Andu <bog495@REDACTED> wrote:
>>>
>>>> Yes but the point is to have a default configuration that can be
>>>> overridden by such a mechanism
>>>> if one is configured.
>>>> The 99 percent of cases only need a default behaviour.
>>>>
>>>> The way I see this is to have something like that (all in one):
>>>>
>>>> <LIMIT POST GET>
>>>>         mod_405=my_405_handle_module
>>>> ....
>>>> </LIMIT>
>>>>
>>>> in this way we can also customize the response if a method other than
>>>> GET or POST is sent to the server
>>>>
>>>> On Fri, Feb 13, 2015 at 10:17 AM, Imants Cekusins <imantc@REDACTED>
>>>> wrote:
>>>>
>>>>> > Traffic with methods not allowed should be discarded with 405
>>>>>
>>>>> you see, someone else might prefer another action depending on method
>>>>> not allowed.
>>>>>
>>>>> a dedicated attribute may be convenient but then someone would ask:
>>>>> "how do I change the response code? how do I redirect?". Current
>>>>> approach gives you choice.
>>>>>
>>>>> one of those cases when there is more than one approach, a prefers  A,
>>>>> b prefers B. Both have a valid point.
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150628/c56d7ceb/attachment.htm>