<div dir="ltr"><div><div><div><div>Hi,<br><br></div>About yaws as reverse proxy..<br><br></div><div>I want to use yaws as a reverse proxy in a<br></div><div>http -> http setup. no ssl involved whatsoever.<br></div><div><br></div><div>I am interested in interception module where I want <br></div><div>to apply various checks on headers, query string, etc<br></div><div>making this some kind of www firewall .<br></div><div><br>Is this feature of yaws production ready ?<br></div><br><br></div>Thanks,<br></div>Bogdan<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 6:14 PM, Steve Vinoski <span dir="ltr"><<a href="mailto:vinoski@ieee.org" target="_blank">vinoski@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<span class="HOEnZb"><font color="#888888"><div><br></div><div>--steve<br><div><div><br></div><div><br></div></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 4:30 AM, Bogdan Andu <span dir="ltr"><<a href="mailto:bog495@gmail.com" target="_blank">bog495@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Yes but the point is to have a default configuration that can be overridden by such a mechanism<br></div>if one is configured.<br></div>The 99 percent of cases only need a default behaviour.<br><br></div>The way I see this is to have something like that (all in one):<br><br></div><LIMIT POST GET><br></div><div>        mod_405=my_405_handle_module<br>....<br></div></LIMIT><br><br></div>in this way we can also customize the response if a method other than GET or POST is sent to the server<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 13, 2015 at 10:17 AM, Imants Cekusins <span dir="ltr"><<a href="mailto:imantc@gmail.com" target="_blank">imantc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Traffic with methods not allowed should be discarded with 405<br>
<br>
</span>you see, someone else might prefer another action depending on method<br>
not allowed.<br>
<br>
a dedicated attribute may be convenient but then someone would ask:<br>
"how do I change the response code? how do I redirect?". Current<br>
approach gives you choice.<br>
<br>
one of those cases when there is more than one approach, a prefers  A,<br>
b prefers B. Both have a valid point.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>