change proxyTable routing target path

[max-mapper]

given a proxyTable router like this:

{
  "baz.com/taco": "127.0.0.1:8098",
  "pizza.com/taco/muffins": "127.0.0.1:8099",
}

requests from baz.com/taco will get proxied to 127.0.0.1:8098 and requests from pizza.com/taco/muffins will get proxied to 127.0.0.1:8099/taco

the old behavior was baz.com/taco to 127.0.0.1:8098/taco and pizza.com/taco/muffins to 127.0.0.1:8099/taco/muffins

[dominictarr]

looks good, reviewing.

[manast]

well guys I think the documentation is wrong in this regard. According to the documentation in the main page, it does not imply that a route like this 'foo.com/baz': '127.0.0.1:8001', means that requests will be forwarded to 127.0.0.1:8001/baz, in fact it says: incoming requests to 'foo.com/baz' and forward them to '127.0.0.1:8001'.
This behaviour is in fact giving me huge amounts of frustration. I cannot see the point of forwarding to 127.0.0.1:8001/baz. It doesn't seem to fullfil any useful usecase. I had solved this problem with a custom middleware, but unfortunately, bugs in the handling of websockets make this approach impracticable now... help please! :).

From the Readme:
A Proxy Table is a simple lookup table that maps incoming requests to proxy target locations. Take a look at an example of the options you need to pass to httpProxy.createServer:

var options = {
router: {
'foo.com/baz': '127.0.0.1:8001',
'foo.com/buz': '127.0.0.1:8002',
'bar.com/buz': '127.0.0.1:8003'
}
};
The above route table will take incoming requests to 'foo.com/baz' and forward them to '127.0.0.1:8001'. Likewise it will take incoming requests to 'foo.com/buz' and forward them to '127.0.0.1:8002'.

[manast]

btw, the issue I am referring to is #112

[dominictarr]

@manast if you use node-http-proxy at 4d50915 then that is the behavior that you will get, is that what you want?

the first type of proxying could be useful for sharding your app, but foo.com/db: host:port could be useful for sidestepping the single origin policy... which is probably much more useful.

[manast]

@dominictarr

The reporter is complaining that pizza.com/taco/muffins is proxied to 127.0.0.1:8099/taco instead of to 127.0.0.1:8099/muffins/taco, which according to the documentation are both wrong behaviors, or at least thats my interpretation of what I read. But besides that I think that proxying just to 127.0.0.1:8099 should be the most common use case, i.e., you have several servers and you want to place them under different sub routes (to avoid for instance cross-browser scripting problems, etc). If we keep the subroutes in the proxied request, then we are creating a coupling between the proxy and the servers, both need to be always in sync, which I dont think is a good idea. Every server should be agnostic of where the proxy configurator has placed it...
Wouldnt it be better to support this kind of routes if we really want to keep subroutes:

var options = {
router: {
'foo.com/baz': '127.0.0.1:8001/baz',
'foo.com/buz': '127.0.0.1:8002/buz',
'bar.com/buz': '127.0.0.1:8003/buz'
}
};

?

[manast]

On top of everything I am also a bit confused about how to use the proxy in conjunction with socket.io+express. Before, everything worked without any hassle, but now I am not sure If I need to do something else or not :/

[max-mapper]

@manast I like the subroutes API you defined, it seems more robust than my solution, which is more robust than what used to be in node-http-proxy. If you make a pull request to support your suggestion then I'd be happy to use it.

[dominictarr]

@manast, your description is better. it would probably only be a small change from what @maxogden has done to get that behavior.

[manast]

guys, it may be me, but what is now on the repo is not working at all. For example, If I defined a route like this:

"pizza.com/taco/muffins": "127.0.0.1:8099"

and I get the following incoming request: pizza.com/taco/muffins/tomato I should expect (according to the latest merge):
127.0.0.1:8099/taco/muffins/tomato while I am getting (if I have run the tests correctly): 127.0.0.1:8099/taco

Of course I would have preferred 127.0.0.1:8099/tomato
I am btw hacking on the code as we speak, but I have problems when adding new test cases, I always get this error: Error: EADDRINUSE, Address already in use

Strange that I just can't add a new case :/

regards.