forward 443 requests to correct (?) port

[Francis Daly]

On Mon, Sep 19, 2022 at 12:25:04PM -0600, Brian Carey wrote:

Hi there,

> Maybe I'm misunderstanding how this should work. Can I use non-ssl
> connections for upstream servers when the originating request is https?

>From nginx's point of view: yes, not a problem.

>From the upstream application's point of view: it will often want to
know what scheme://host:port/prefix/ it should use when creating links
in what it produces; and it might be configured to only "work" when the
connection from the client is https.

So you might need to configure that side of things in some way to
believe that "anything from nginx" is trustworthy; or that "anything with
specific http headers" is trustworthy, or something else that depends
on this particular application.

> I'm forwarding nginx requests to an apache server listening on 8080.
> Everything works fine if I explicitly use http but not https. My nginx site
> itself has no problem with https and all http traffic is forwarded to https.
> However when I try to go to wordpress (on apache) I get an error in my
> browser that I am forwarding plain http to https, and indeed the port I see
> in the browser is 443 not 8080. Again if I explicitly request http I'm good
> but it fails with https. Why is nginx forwarding this traffic to 443 instead
> of 8080? Or probably better how do I change this behavior?

I'm a bit unclear on what exactly you are reporting, sorry.

In general, the browser talks to nginx only; and nginx talks to upstream
only; and the browser should not necessarily be aware that it is not
talking to upstream. So if you have https://nginx reverse proxying to
http://apache:8080, the browser should never know or care about port 8080.

It's probably good to be very clear about what should be talking to what;
and about what is talking to what. And I suspect that that will need
some specific copy-paste details from you, if you are unsure.

> So I'm trying to find out how nginx makes that decision. This is the stanza
> nginx conf file.
> 
> server {
>         listen 80 default_server;
>         listen [::]:80;
>         server_name biscotty.me;
>         return 301 https://$hostname$request_uri;
> }

Ok. Any http request to nginx (on port 80), gets nginx inviting the
browser to make a https request.

(You may want $server_name or $host, instead of $hostname; but anything
that works is good.)

> server{
> 
>  listen 443 ssl http2;
...
> location /wordpress {
>                 proxy_pass http://0.0.0.0: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;
>         }
> 
> }

A https request from the browser to /wordpress/x will lead to a http
request from nginx to /wordpress/x. I'm not sure that 0.0.0.0:8080 always
works as an IP:port to connect to (I'd probably use a specific IP there);
but if it works for you, it is good.

What happens after that, is entirely up to wordpress on apache.

If you can show the specific request that you make and the response that
you get, perhaps using "curl -i" in order to avoid browser caching or
"friendly" response interception, then it may become clear what problem
exists and what solution to it can be found.

I suspect that you will want to omit ":8080" from the proxy_set_header.

When you show one request and its response, it may become clear whether
your current proxy_redirect setting is appropriate here.

(And I do think that, in the past, wordpress was not happy being installed
anywhere other than the root of the web service -- it did not work
well in a subdirectory. It may well be that that is no longer the case,
and things will all Just Work now.)

Cheers,

	f
-- 
Francis Daly        francis at daoine.org