> $ bin/httpGate 3000 8080 "" 8081 8082
Oops, you found a bug! At least (and to my own surprise), it doesn't
work that way. I must confess I never tested with ports different from
the protocol-specific default ports 80 and 443.
The problem is that the application server generates a "<base href=" tag
for further transactions during that session, but it doesn't know about
the fact that 'httpGate' was called with another port (here: 3000). So
the generated pages contain URLs like
(i.e. without ":3000") and thus the browser can't find them, because it
tries to contact port 80.
> e...@saidin $ ./dbg app/main.l -main -go
> : 22487 * 2010-08-25 09:01:10 admin
> which i guess is alright.
Yes. The first page and the login succeeded. But the answer page can't
Do you need this kind of setup for some special reason? After all, the
main purpose of 'httpGate' is to proxy all requests to the default port
to app-specific ports like 8080. If you pass :3000 to the browser, you
could as well directly pass :8080.
If such a setup were indeed necessary (e.g. because you have no
permission to start 'httpGate' at port 443, but you need it for HTTPS),
then the protocol between 'httpGate' and the application server would
need to be extended a little, passing the alternate port (3000). No big
deal, but it seems nobody needed that until now ;-)