Hi Francis.

Thanks for your continued help.

On Sat, Apr 15, 2017 at 8:50 PM, Francis Daly <francis@daoine.org> wrote:

> On Sat, Apr 15, 2017 at 02:47:26PM +0530, Ajay Garg wrote:
>
> Hi there,
>
> > If there is no forwarded-port in listening state (port 5000 in this case)
> > for the upstream-server, the request suitably returns a 502 error. More
> > importantly, the $arg_upstream_protocol does seem to be parsed properly
> ::
>
> Why do you have $arg_upstream_protocol? What is its purpose?
>
> After you answer that, consider: why do you not also have
> $arg_forwarded_port?
>
> If the port to connect to, and the protocol to connect with, are
> conceptually analogous, they should probably be handled in the same way.
>


Our architecture is as follows ::

Proxy-Server <==> Gateway <==> End-Server

Proxy-Server and Gateway are connected via a ssh-reverse-tunnel.
The port over which they are connected remains the same, as long as the
Gateway is same.
So, $forwarded_port can be safely set in the map.

Gateway and End-Server communicate via the "other end" of the
ssh-reverse-tunnel.
The End-Server here might change, and so the communication can either be
over http or https.
This information is passed as a GET-param, when making the request to the
Proxy-Server.
So, $arg_upstream_protocol comes into picture.



> (Set them both in maps.)
>


I have already tried this via

map $remote_user $forwarded_protocol {

ajay $arg_upstream_protocol
}

.....
......
proxy_pass $forwarded_protocol://127.0.0.1:$forwarded_port;

but I get the same results as per my previous emails.








>
> > So, the GET-param is being parsed fine (as evident from case a), seems I
> > need to do some url-rewritings while the requests move to and from
> between
> > nginx and upstream-server, right?
>
> One request gets one response. If the response is a http 301, the next
> request is a whole new request that should be considered separately.
>
> If at all possible, do not design things so that you need to edit the
> upstream response body before sending it to the client.
>
> So: what is the output of "curl -v" on the first request?
>

Following is received ::

#####################################################
curl -v -k https://ajay:garg@1.2.3.4/?upstream_protocol=http
* Hostname was NOT found in DNS cache
* Trying 1.2.3.4...

* Connected to 1.2.3.4 (1.2.3.4) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS Unknown, Unknown (22):
* SSLv3, TLS handshake, Client hello (1):

* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server hello (2):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, CERT (11):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server finished (14):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv2, Unknown (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Finished (20):
* SSLv2, Unknown (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=IN; ST=Delhi; L=Delhi; O=Home; OU=Home; CN=www.home.com;
emailAddress=support@home.com
* start date: 2017-04-09 03:53:25 GMT
* expire date: 2027-04-07 03:53:25 GMT
* issuer: C=IN; ST=Delhi; L=Delhi; O=Home; OU=Home; CN=www.home.com;
emailAddress=support@home.com
* SSL certificate verify result: self signed certificate (18),
continuing anyway.
* Server auth using Basic with user 'ajay'
* SSLv2, Unknown (23):
> GET /?upstream_protocol=http HTTP/1.1
> Authorization: Basic abcdefg
> User-Agent: curl/7.37.1
> Host: 1.2.3.4
> Accept: */*
>
* SSLv2, Unknown (23):
< HTTP/1.1 200 Ok
* Server nginx/1.11.13 is not blacklisted
< Server: nginx/1.11.13
< Date: Sun, 16 Apr 2017 03:42:22 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 75
< Connection: keep-alive
< Last-Modified: Sat, 08 Aug 2015 04:40:50 GMT
<
<script>
<!--
window.location.href = "/cgi-bin/webproc";
-->
* Connection #0 to host 1.2.3.4 left intact
#####################################################


Strangely, when request is done by curl, absolutely nothing appears in
/var/log/nignix/error.log, whereas when done through the browser, logs
appear in /var/log/nginx/error.log as per my previous emails.


Beginning to feel a little lost again :-\
But I believe that the experts will sail me through..








>
> What do you want the output to be, in your design?
>

Things work fine if I hardcode http/https in proxy_pass directive.
It's only when I need to use to parse-and-use "upstream_protocol" from the
GET-param (which can only be equal to http/https) that I start facing
problems.




>
> f
> --
> Francis Daly francis@daoine.org
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>



Thanks and Regards,
Ajay
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx