Re: [naviserver-devel] Simple http proxy handler

[Vlad S. <vl...@cr...>]

It started as small proxy to handle special cases when we need access to 
private LAN inside our LAN to provision some servers via WEB. I never 
intended to make it full HTTP proxy but even in current state it does 
work and we access our appliance boxes though this module.

To make it more usefull, it needs to be in separate module, i agree.
Currently it uses internal proxy which is in the core, that's why 
specific register by protocol method, this is how it defined and used in 
the op.c and used in queue.c.

Not sure about transparent proxy on Tcl level, this needs a lot of code 
  it is more like proxy driver as i see it.

Stephen Deasey wrote:
> tcl/http.tcl:
> 
> if {[ns_config -bool ns/server/[ns_info server] enablehttpproxy off]} {
>     ns_register_proxy GET  http ns_proxy_handler_http
>     ns_register_proxy POST http ns_proxy_handler_http
>     nsv_set ns:proxy allow [ns_config ns/server/[ns_info server] allowhttpproxy]
> }
> 
> 
> This is going to break on the first HEAD request...
> 
> This really should be a module of it's own, in the external modules
> directory.  So far the functionality is pretty limited and arbitrary,
> but obviously really useful.  But there's a lot that needs to be added
> to be a fully useful proxy implementation, and probably a lot of
> people who would be interested.  This really would benefit from being
> an external module, with it's own release cycle etc.
> 
> Some thought needs to go into the API for registering proxy handlers.
> 
> At the moment the handler is triggered exclusively by the client
> sending the full protocol and host  in the request line, i.e.:
> 
>     GET http://foo.com/blah.html HTTP/1.0
> 
> The problem is that the spec says HTTP 1.1 clients are supposed to
> send the full protocol and host on each request.  If we move it full
> HTTP 1.1 compliance, this is going tp break.
> 
> As it stands, the proxy code is only triggered if the client is
> explicitly configured to treat the server as it's proxy, but it's also
> useful to have a transparent proxy, e.g. to send some section of the
> URL hierarchy to a legacy Apache server :-)
> 
> So, removing the requirement that the full protocol and host needed to
> trigger the proxy code isn't such a problem, it would enable
> transparent proxies.
> 
> Registering proxy handlers to a specific method / protocol combination
> seems wrong to me.  Even if you added HEAD to the list of methods in
> the configuration, what happens when a client send something else?
> Shouldn't it be passed through to the back end server, which perhaps
> does know how to handle the method?
> 
> 
> We needs some ideas for what the API for registering proxy handlers
> should look like.  Do we even need one?  Is the existing
> ns_register_proc not sufficient?  Perhaps if we added the ability to
> register a proc for a 'default' method, *, that would do?
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/