<div dir="ltr"><div>Hi Francis.<br><br></div>Thanks for your continued help.<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 15, 2017 at 8:50 PM, Francis Daly <span dir="ltr"><<a target="_blank" href="mailto:francis@daoine.org">francis@daoine.org</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">On Sat, Apr 15, 2017 at 02:47:26PM +0530, Ajay Garg wrote:<br>
<br>
Hi there,<br>
<br>
</span><span class="gmail-">> If there is no forwarded-port in listening state (port 5000 in this case)<br>
> for the upstream-server, the request suitably returns a 502 error. More<br>
> importantly, the $arg_upstream_protocol does seem to be parsed properly ::<br>
<br>
</span>Why do you have $arg_upstream_protocol? What is its purpose?<br>
<br>
After you answer that, consider: why do you not also have<br>
$arg_forwarded_port?<br>
<br>
If the port to connect to, and the protocol to connect with, are<br>
conceptually analogous, they should probably be handled in the same way.<br></blockquote><div><br><br>Our architecture is as follows ::<br><br><div> Proxy-Server <==> Gateway <==> End-Server<br></div><div><br></div><div>Proxy-Server and Gateway are connected via a ssh-reverse-tunnel.<br>The port over which they are connected remains the same, as long as the Gateway is same.<br></div><div>So, $forwarded_port can be safely set in the map.<br><br></div><div>Gateway and End-Server communicate via the "other end" of the ssh-reverse-tunnel.<br></div><div>The End-Server here might change, and so the communication can either be over http or https.<br></div><div>This information is passed as a GET-param, when making the request to the Proxy-Server.<br></div>So, $arg_upstream_protocol comes into picture. <br><br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
(Set them both in maps.)<br></blockquote><div><br><br></div><div>I have already tried this via<br><br></div><div>map $remote_user $forwarded_protocol {<br> <br></div><div> ajay $arg_upstream_protocol<br>}<br><br>....<br>.....<br> proxy_pass $forwarded_protocol://127.0.0.1:$forwarded_port;<br><br></div><div>but I get the same results as per my previous emails.<br><br></div><div><br></div><br><div><br><br></div><div><br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<span class="gmail-"><br>
> So, the GET-param is being parsed fine (as evident from case a), seems I<br>
> need to do some url-rewritings while the requests move to and from between<br>
> nginx and upstream-server, right?<br>
<br>
</span>One request gets one response. If the response is a http 301, the next<br>
request is a whole new request that should be considered separately.<br>
<br>
If at all possible, do not design things so that you need to edit the<br>
upstream response body before sending it to the client.<br>
<br>
So: what is the output of "curl -v" on the first request?<br></blockquote><div><br>Following is received ::<br><br>##############################<wbr>#######################<br>curl -v -k <a href="https://ajay:garg@1.2.3.4/?upstream_protocol=http">https://ajay:garg@1.2.3.4/?upstream_protocol=http</a><br>* Hostname was NOT found in DNS cache<br>* Trying 1.2.3.4...<br><br>* Connected to 1.2.3.4 (1.2.3.4) port 443 (#0)<br>* successfully set certificate verify locations:<br>* CAfile: none<br> CApath: /etc/ssl/certs<br>* SSLv3, TLS Unknown, Unknown (22):<br>* SSLv3, TLS handshake, Client hello (1):<br><br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, Server hello (2):<br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, CERT (11):<br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, Server key exchange (12):<br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, Server finished (14):<br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, Client key exchange (16):<br>* SSLv2, Unknown (20):<br>* SSLv3, TLS change cipher, Client hello (1):<br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, Finished (20):<br>* SSLv2, Unknown (20):<br>* SSLv3, TLS change cipher, Client hello (1):<br>* SSLv2, Unknown (22):<br>* SSLv3, TLS handshake, Finished (20):<br>* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384<br>* Server certificate:<br>* subject: C=IN; ST=Delhi; L=Delhi; O=Home; OU=Home; CN=<a href="http://www.home.com">www.home.com</a>; emailAddress=<a href="mailto:support@home.com">support@home.com</a><br>* start date: 2017-04-09 03:53:25 GMT<br>* expire date: 2027-04-07 03:53:25 GMT<br>* issuer: C=IN; ST=Delhi; L=Delhi; O=Home; OU=Home; CN=<a href="http://www.home.com">www.home.com</a>; emailAddress=<a href="mailto:support@home.com">support@home.com</a><br>* SSL certificate verify result: self signed certificate (18), continuing anyway.<br>* Server auth using Basic with user 'ajay'<br>* SSLv2, Unknown (23):<br>> GET /?upstream_protocol=http HTTP/1.1<br>> Authorization: Basic abcdefg<br>> User-Agent: curl/7.37.1<br>> Host: 1.2.3.4<br>> Accept: */*<br>> <br>* SSLv2, Unknown (23):<br>< HTTP/1.1 200 Ok<br>* Server nginx/1.11.13 is not blacklisted<br>< Server: nginx/1.11.13<br>< Date: Sun, 16 Apr 2017 03:42:22 GMT<br>< Content-Type: text/html; charset=utf-8<br>< Content-Length: 75<br>< Connection: keep-alive<br>< Last-Modified: Sat, 08 Aug 2015 04:40:50 GMT<br>< <br><script><br><!--<br> window.location.href = "/cgi-bin/webproc";<br>--><br>* Connection #0 to host 1.2.3.4 left intact<br>##############################<wbr>#######################<br><br><br></div><div>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.<br><br><br></div><div>Beginning to feel a little lost again :-\<br></div><div>But I believe that the experts will sail me through..<br clear="all"></div><div><br><br><div class="gmail_signature"><br></div>
<br><br><br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
What do you want the output to be, in your design?<br></blockquote><div><br></div><div>Things work fine if I hardcode http/https in proxy_pass directive.<br></div><div>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.<br></div><div><br><br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
f<br>
--<br>
Francis Daly <a href="mailto:francis@daoine.org">francis@daoine.org</a><br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a target="_blank" rel="noreferrer" href="http://mailman.nginx.org/mailman/listinfo/nginx">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br><br clear="all"><br>Thanks and Regards,<br>Ajay</div></div>