First I'll set the stage so you know where I'm coming from.

I wrote a specialized proxy server that uses HTTP::Proxy as it's core, with other features like proxy cookie support, authentication, and domain redirection built in. The program is targeted primarily toward wireless Internet users (like cell phones) that want to run their own proxy server to provide Internet access for their device, instead of paying their carrier $5 a month to use the carrier's proxy. These wireless users have some special needs, not the least of which being that most cell phone Internet browsers don't have cookie support (they just ignore them). So, my proxy server grabs Set-Cookie headers and stores them on a per-user basis, and then puts appropriate Cookie headers into requests when the user requests a page from a host for which cookies have been stored. Another specialized need for these users is that most carriers try to make it difficult for the user to run their own proxy by hard coding the home page of the browser to something impossible like "http://homepage". My proxy server identifies those "local domain" requests (anything without a TLD) and redirects the browser to a homepage of the users choice.

However it has recently come to light that one major carrier locks the phone's homepage to "proxy:homepage". This is insidious because most proxy servers (HTTP::Proxy included) see "proxy:" as specifying a protocol/scheme (like http, https, etc.). HTTP::Proxy therefore returns a 501 error when a request for "proxy:homepage" comes through.

I was able to fix this situation with a change to HTTP::Proxy. At line 328 in Proxy.pm in 0.15 contains this code:

I remarked out that code and replaced it with this code:

What this does is basically say, if you get a request for a scheme/protocol you don't know about, change the protocol to 'http'. This allows the request to pass through and make it into my request header filter, where I identify it as a local domain request (because the host is blank and therefore there is no TLD which is what I am looking for). Since my proxy redirects all local domain requests to the user's homepage of choice, it cleanly works around the "proxy:homepage" problem.

I'm not saying you'd want HTTP::Proxy to work this way by default. What would be nice however is something like an 'overrideUnknownSchemes' mutator that if set to a true value would cause HTTP::Proxy to behave the way my new code illustrates. This would save me from having to run a proprietary (modified) version of HTTP::Proxy (which is something I'd rather not do).

I realize this is a little esoteric and might not matter to anyone but me, but it is a simple change and you never know who might benefit from it in some other oddball scenario.

I have released the source code for my proxy server, but not on CPAN. It is available at www.HoTTProxy.org. I don't know if it's good enough for CPAN. :-) It started out just being for me, and then I decided to release it for all to use so I had to clean it up a bit and make it a little more user friendly. I'm also working on a web based administration console for it using the HTTP::Server::Simple::CGI module (which is also great).

When you say you'd "return false" if the protocol is not supported, it sounds like the request would be short circuited and wouldn't make it through to the filters (and for my purposes, it needs to). If we wanted to make the concept a little more generic perhaps instead of a true/false mutator that always maps unknown schemes to http, it would make more sense to have a mutator like:

so that each developer could choose, for their particular situation, what protocol to treat unsupported protocols as. This would provide maximum flexibility and allow the requests to pass through to the various filters, etc., just like any other request of that protocol.

What do you think?

I like the concept of being able to add to the list of supported schemes without having to modify the Proxy.pm. Adding 'proxy' to the list of protocols allowed seems to work OK using this code:

I had to add the $proxy->init() because Proxy.pm was saying:

if I didn't. However, even after getting it to take the additional "allowed" protocol, the filter is dying with this error, and I don't know why:

I tried reading the code around line 630 in Proxy.pm but can't see why it should think that scheme 'proxy' is unsupported once it is added to protocols_allowed. Just to ensure that 'proxy' really was in protocols_allowed, I even tried just hard coding it into the list in line 225 of Proxy.pm, and I still get the same "unsupported scheme" error.

Stumped for now. I think I should go to bed. It will be light soon.

Thanks, this sounds perfect. I have subscribed to the two mailing lists you referenced. I will also download the latest snapshot of the CVS repository and do some testing with it.

Thanks again!