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?

Reply via email to