Thanks for your input. I have spent quite some time on this, and have failed on "rewrite".

It all works using a different port number but *without* SSL -- the moment I add the Certbot back in (see config below) I get "Error code: SSL_ERROR_RX_RECORD_TOO_LONG".

Also, same server, on default port 80, works perfectly as https, but if I add :80 to the requested URL, I get the same "Error code: SSL_ERROR_RX_RECORD_TOO_LONG"...

All suggestions warmly welcomed, thanks. ...and stay well - Paul.

server {

    listen 8084;
#    listen 443 ssl;

# ssl_certificate /etc/letsencrypt/live/serv1.example.com/fullchain.pem; # managed by Certbot # ssl_certificate_key /etc/letsencrypt/live/serv1.example.com/privkey.pem; # managed by Certbot
#    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
#    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    server_name my_app;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/ships-error_log;

    proxy_buffering off;

    location / {
        proxy_pass http://192.168.xxx.yyy:8084;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }

}

#server {
#    if ($host = serv1.example.com) {
#        return 301 https://$host$request_uri;
#    } # managed by Certbot

# automatically sets to https if someone comes in on http
#    listen 8084;
#    listen 443 ssl;
#    server_name serv1.example.com;
#    rewrite     ^   https://$host$request_uri? permanent;
#}





On 2020-04-14 6:39 p.m., Francis Daly wrote:
On Tue, Apr 14, 2020 at 04:38:51PM -0400, Paul wrote:

Hi there,

My problem is that I need to split serv1.example.com to two physical servers
(both fully functional on LAN). The first (192.168.aaa.bbb) serving static
https works fine. But I cannot "rewrite" (redirect, re-proxy?) to the second
server (192.168.xxx.yyy, Perl cgi) where the request comes in as
https://serv1.example.com/foo and I need to get rid of "foo"

http://nginx.org/r/proxy_pass -- proxy_pass can (probably) do what
you want, without rewrites. The documentation phrase to look for is
"specified with a URI".

        "rewrite ^(.*serv1\.example\.com\/)foo\/(.*) $1$2 permanent;" (tried
permanent, break, last and no flags)

"rewrite" (http://nginx.org/r/rewrite) works on the "/foo" part, not the
"https://"; or the "serv1.example.com" parts of the request, which is why
that won't match your requests.

     location /foo {           # big db server, perfect on LAN, PERL, cgi
         # rewrite ^/foo(.*) /$1 break;   #tried permanent, break, last and
no flags

That one looks to me to be most likely to work; but you probably need
to be very clear about what you mean when you think "it doesn't work".

In general - show the request, show the response, and describe the response
that you want instead.

         # rewrite ^/foo/(.*)$ /$1 last;   #tried permanent, break, last and
no flags
         rewrite ^(.*serv1\.example\.com\/)foo\/(.*) $1$2 permanent; #tried
permanent, break, last and no flags
         proxy_pass http://192.168.xxx.yyy:8084;
         proxy_set_header Host $host;
         proxy_http_version 1.1;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

I suggest trying

     location /foo/ {
         proxy_pass http://192.168.xxx.yyy:8084/;
     }

(note the trailing / in both places) and then seeing what else needs to
be added.

Note also that, in any case, if you request /foo/one.cgi which is really
upstream's /one.cgi, and the response body includes a link to /two.png,
then the browser will look for /two.png not /foo/two.png, which will
be sought on the other server. That may or may not be what you want,
depending on how you have set things up.

That is: it is in general non-trivial to reverse-proxy a service at a
different places in the url hierarchy from where the service believes
it is located. Sometimes a different approach is simplest.

server {

# automatically sets to https if someone comes in on http
     listen 80;
     listen 8084;

Hmm. Is this 8084 the same as 192.168.xxx.yyy:8084 above? If so, things
might get a bit confused.

Good luck with it,

        f



  \\\||//
   (@ @)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____| mailto:[email protected] _|____|____|
_______________________________________________
nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx

Reply via email to