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.
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".
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 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).
Anyways, I was wrong in thinking that the proxy worked with localhost:2000
as if it were inside a box and simply gave inputs and took outputs. It
seems that the proxy directly serves the client to the original URL of
/projects/CS32Brewer...
I was afraid that I'd have to configure the SSL as well given that I
previously had complaints from the server of insecure requests to http;
fortunately, something just clicked and it works fine....
Thank you for all your help and patience, let me know if you'd like any
more details. I apologize for my vagueness and ambiguity so thank you for
sticking with me on it.
On Thu, Aug 27, 2015 at 12:12 AM, Kurtis Rader <kra...@skepticism.us> wrote:
> On Tue, Aug 25, 2015 at 10:25 PM, Steven Shi <steven200...@gmail.com>
> wrote:
>
>> The "app" consists of a maven built java back-end which utilizes the
>> maven build of apache spark ("http://sparkjava.com/";). To my
>> understanding, the spark API initiates a Jetty server which listens on a
>> specified port for GET / POST requests. It then either processes the data
>> sent in a POST request or simply returns the html/css/js page for a GET
>> request.
>>
>
> You really need to stop using the term "app" for every piece of software
> involved in this problem. You've used "app" to refer to the jQuery client
> front end and the Java backend and possibly the Apache HTTP middle layer.
> Not to mention the URI prefix being proxied.
>
>
>> When I said "the port 2000 is lost", I meant that if I go in to the app
>> through the proxy /app and attempt to issue GET / POST commands via the
>> jQuery front end interface, google's developer console shows the remote
>> address as my_ip:(80, 443) and the request URL is simply
>> my_hostname/command. Likewise, the origin and the host are incorrect.
>>
>
> I can't tell from the Chrome developer console snapshot if the "POST
> https://stevenshi.me/run"; request that failed with a 404 status was due
> to a redirect or if it was the original request made by the browser client
> code. If it was the original request then something is wrong in how you
> have told the client code which URI to use. If it was due to a redirect the
> question becomes whether the redirect is from Apache or your Spark backend.
>
> I'm willing to bet the problem is the Spark backend is issuing a HTTP
> redirect that leads to the Apache middle layer no knowing how to handle the
> subsequent request. The solution might be as simple as enabling rewriting
> of proxied HTML with this directive in your virtual host:
>
> ProxyHTMLEnable On
>
> That will require an appropriate "LoadModule proxy_html_module" in your
> Apache config.
>
> Your Apache config proxies the URI prefix "/projects/CS32Brewer/". Is
> that the URI prefix your browser client code is using? Does the Apache
> access log show requests from the browser with the URI prefix? Have you
> enabled higher levels of debug output from Apache as I suggested? If so
> what does the Apache error log show for a failing request?
>
>
>> If HTTP_HOST is the "Host:" shown in google dev console "Request
>> Headers", the app is not setting it correctly on /app (it is "my_hostname"
>> rather than "my_hostname:2000").
>> If HTTP_HOST is not what's said above, then how do I check what it is?
>>
>
> What do you mean by "correctly on /app"? Nowhere in the data you've
> provided so far, in particular the Apache virtual host configuration, is a
> URI prefix of "/app" referenced. If you're using that as a synonym for
> "/projects/CS32Brewer" please say so.
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
