Never mind.
I created two different credentials, one which forwards via http-protocol,
and the other which forwards via https-protocol.
Thanks everyone (especially Francis) for all the help !!!
Thanks and Regards,
Ajay
On Sun, Apr 16, 2017 at 9:49 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> Hi Francis.
>
> Thanks for your continued help.
>
> On Sat, Apr 15, 2017 at 8:50 PM, Francis Daly <fran...@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=supp...@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=supp...@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 fran...@daoine.org
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
>
> Thanks and Regards,
> Ajay
>
--
Regards,
Ajay
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
