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

I'll try to clearly state what I did.

When you said "Your Apache config proxies the URI prefix "/projects/CS32Brewer/". Is that the URI prefix your browser client code is using?", it occurred to me that if the Host was anchored to "localhost:80" and couldn't be changed to "localhost:2000", I could try to proxy the requests themselves. Disclaimer*: I don't know if this logic of thinking was entirely correct.

My thinking was that if a request for "/projects/CS32Brewer/" results in "localhost:2000", then wouldn't a request for "/projects/CS32Brewer/request" result in "localhost:2000/request"?

Therefore I changed all the absolute path requests from "/request" (which would result in "localhost:80/request") to "./request" which takes the parent directory (in this case "/projects/CS32Brewer/") and appends the request to that parent directory.

It turns out the request itself proxies.

The weirdest thing is that I removed proxypassreverse as well as the proxy_html module.

All I have in place is proxypass "/projects/CS32Brewer/" "http://localhost:2000".

The second weird thing I was not expecting was that my SSL problem was suddenly corrected as well. I originally had a solution this morning that used absolute pathing for the requests ("/request" would be "http://localhost:2000/request") but this turned out to be a bit of work to maintain in whenever I moved anything around / changed ports etc; it also did not work over SSL and complained about insecure requests to an http site. Somehow, using the relative pathing from the parent directory killed two birds with one stone while being extremely flexible.

I do not currently have my configuration page but would be happy to share it if it clarifies things. I'm quite befuddled by the results myself. Please let me know any further clarifications I can make.

Last thing to note: I tested this configuration with a second project that has the same build and it works perfectly fine over SSL as well.

On Fri, Aug 28, 2015 at 12:23 AM, Kurtis Rader <krader@xxxxxxxxxxxxx> wrote:

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