Hi,
I have an app running at port 8239 on biscotty.me. If I access the app
directly everything works as expected.
I am able to use proxy_pass to forward https:/biscotty.me/striker to the
main page of my app. The problem is that all of the links in the app
result in a page not found error from the apache server handling
requests to /. So it seems like the port number information is somehow
being lost in translation?
This is my conf:
Okay I seem to have solved this. I re-wrote the app urls to mount all
directories under /striker, something unnecessary for the app itself but
necessary for nginx to properly forward. I also removed the rewrite rule
below.
Thanks by the way for the help you give here.
Brian
On 10/30/22 11:20, Brian Carey wrote:
>
> Hi,
>
> I have an app running at port 8239 on biscotty.me. If I access the app
> directly everything works as expected.
>
> I am able to use proxy_pass to forward https:/biscotty.me/striker to
> the main page of my app. The problem is that all of the links in the
> app result in a page not found error from the apache server handling
> requests to /. So it seems like the port number information is somehow
> being lost in translation?
>
> This is my conf:
>
> ```
>
> location /striker {
> rewrite /striker/(.*) /$1 break;
> proxy_pass http://192.168.0.238:8239;
>
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $remote_addr;
> proxy_set_header Host $host:8239;
>
> }
>
> location / {
> proxy_pass http://192.168.0.238:8080/;
> proxy_buffering on;
> proxy_buffers 12 12k;
> proxy_redirect off;
>
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $remote_addr;
> proxy_set_header Host $host:8080;
>
> }
>
> ```
>
>
> ```
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221030/152ba1b5/attachment.htm>
Thinking it through though I think my solution is bad since it implies a
dependency between the urls defined in the program and the location used
in nginx, ie. they must match and the program cannot be proxied at an
arbitrary location. So hopefully there is a better solution than the one
I found. I hope I'm not asking too many questions.
On 10/30/22 11:41, Brian Carey wrote:
>
> Okay I seem to have solved this. I re-wrote the app urls to mount all
> directories under /striker, something unnecessary for the app itself
> but necessary for nginx to properly forward. I also removed the
> rewrite rule below.
>
> Thanks by the way for the help you give here.
>
> Brian
>
> On 10/30/22 11:20, Brian Carey wrote:
>>
>> Hi,
>>
>> I have an app running at port 8239 on biscotty.me. If I access the
>> app directly everything works as expected.
>>
>> I am able to use proxy_pass to forward https:/biscotty.me/striker to
>> the main page of my app. The problem is that all of the links in the
>> app result in a page not found error from the apache server handling
>> requests to /. So it seems like the port number information is
>> somehow being lost in translation?
>>
>> This is my conf:
>>
>> ```
>>
>> location /striker {
>> rewrite /striker/(.*) /$1 break;
>> proxy_pass http://192.168.0.238:8239;
>>
>> proxy_set_header X-Real-IP $remote_addr;
>> proxy_set_header X-Forwarded-For $remote_addr;
>> proxy_set_header Host $host:8239;
>>
>> }
>>
>> location / {
>> proxy_pass http://192.168.0.238:8080/;
>> proxy_buffering on;
>> proxy_buffers 12 12k;
>> proxy_redirect off;
>>
>> proxy_set_header X-Real-IP $remote_addr;
>> proxy_set_header X-Forwarded-For $remote_addr;
>> proxy_set_header Host $host:8080;
>>
>> }
>>
>> ```
>>
>>
>> ```
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221030/2d5dd3c3/attachment.htm>
On Sun, Oct 30, 2022 at 11:56:39AM -0600, Brian Carey wrote:
Hi there,
> Thinking it through though I think my solution is bad since it implies a
> dependency between the urls defined in the program and the location used in
> nginx, ie. they must match and the program cannot be proxied at an arbitrary
> location.
if you have a "back-end" at http://one.internal.example.com/, that is
reverse-proxied behind the public-facing http://example.com/one/ using
the "normal" nginx config fragment
location /one/ { proxy_pass http://one.internal.example.com/; }
then the client browser making the requests does not know that there is
a back-end service.
When the client requests http://example.com/one/two.html, nginx will
ask for http://one.internal.example.com/two.html, and will send the
response http headers and body content back to the client.
If that response contains links or references of the form "three.jpg"
or "./three.jpg", then the client will make the next request for
http://example.com/one/three.jpg, which will get to nginx, which will know
to proxy_pass to the same back-end service, and all will probably work.
If the response contains links of the form "/three.jpg", then the
client will make the next request for http://example.com/three.jpg,
which will get to nginx but will probably not get a useful response,
because nginx knows that it must not proxy_pass to the same back-end
because the local part of the request does not start with /one/. The
user will probably see an error or something that looks broken.
If the response contains links of the form
http://one.internal.example.com/three.jpg, then the client will presumably
fail to resolve the hostname one.internal.example.com, and the user will
probably see an error.
> So hopefully there is a better solution than the one I found. I
> hope I'm not asking too many questions.
Whether or not a particular back-end can be reverse-proxied easily,
or can be reverse-proxied easily at a different local part of the url
hierarchy from where it thinks it is installed, it mostly down to the
back-end application to decide.
In general (and there are exceptions), nginx can readily rewrite the
http response headers, and cannot readily rewrite the http response body,
in order to adjust links or references to other internal resources.
If you control the back-end service, and you know that you want to
reverse-proxy it behind http://example.com/one/, you will probably
find it easier to work with, if you can install the back-end service
at http://one.internal.example.com/one/.
That would make the first two forms of links "Just Work"; and the third
(full-url) form is usually easier to recognise and replace.
> > > I am able to use proxy_pass to forward https:/biscotty.me/striker to
> > > the main page of my app. The problem is that all of the links in the
> > > app result in a page not found error from the apache server handling
> > > requests to /. So it seems like the port number information is
> > > somehow being lost in translation?
More likely, I guess, is that the links are of the second form, to
"/three.jpg" instead of the "three.jpg".
But it could also be related to what the initial request from the client
was -- "/striker" and "/striker/" are different, and I suspect you should
use the with-trailing-slash version in your config "location" line.
But if you already have a working configuration, that's good!
Cheers,
f
--
Francis Daly francis at daoine.org
location /striker { rewrite /striker/(.*) /$1 break; proxy_pass http://192.168.0.238:8239;
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host:8239;
}
location / { proxy_pass http://192.168.0.238:8080/; proxy_buffering on; proxy_buffers 12 12k; proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header Host $host:8080;
}
-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.nginx.org/pipermail/nginx/attachments/20221030/0c729c33/attachment.htm ```