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
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
[EMAIL PROTECTED]
http://www.crystalballinc.com/vlad/
