Re: Re: Proxying From Directory To App On Port (Apache Users)

On Thu, Aug 27, 2015 at 8:21 PM, Steven Shi <steven200796@xxxxxxxxx> wrote:

Hey Kurtis,

I was in the middle of replying and then something clicked for me. I spent the day today working on this one more time and ended up getting it working. I believe my fundamental understanding of a proxy was simply incorrect.

Your comment about the URI prefix was what made it click for me.

I am happy you solved your problem but am concerned you still do not really understand what is happening.

Basically all my requests on the client front end were formatted like so "/command". I mistakenly thought that the client would run these with respect to the host it came from (Jetty returns the client as a result of the initial proxied GET to localhost:2000). Apparently, the client ends up realizing it is no longer on localhost:2000 but is now instead on localhost:80 and was calling the requests as such. This would also make sense why "/command" would result in the GET/POST URL as "localhost:80/command".

The client code running in the browser does not "realize" it is no longer on localhost:2000. At least not in the sense you seem to mean. The browser client code is simply going (that is, making requests) where it was told to go. Specifically, it appears (as I suspected) your Jetty backend has no knowledge it is being proxied and is returning a response containing URIs that implied the Jetty backend could be directly reached on port 80 (because the URIs in its response do not include a port number). When in fact it can only be directly reached on port 2000. This is a very common problem and why the ProxyReversePass directive in conjunction with the proxy_html_module (or other suitable module) exists.

After your comment, I realized that requests also need to have the URI with respect to the original host rather than the proxy on localhost:2000. As such I changed every instance of "/command" to "./command" and now everything works perfectly.

I don't understand what you did. For the benefit of myself, and everyone else reading this email thread, can you provide more detail regarding what your changed?

I did in fact enable the high levels of debug output and could make no sense of them unfortunately...somehow one request ended up in 200 lines of garble (I cleared the log beforehand).

That is often the case. Which is why it is important to perform one experiment at a time; i.e., issuing one client request then saving the log files for analysis. If you do not minimize the number of variables (e.g., the number of unrelated HTTP requests) it can be very difficult to derive any conclusions from the data.

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank