Hi Francis. I tried the curl method, and I happened to land on an interesting observation.
a) 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 :: ##################################################### 2017/04/15 09:08:56 [error] 16039#16039: *40 connect() failed (111: Connection refused) while connecting to upstream, client: 182.69.5.226, server: , request: "GET /?upstream_protocol=http HTTP/1.1", upstream: " http://127.0.0.1:5000/?upstream_protocol=http", host: "1.2.3.4" ##################################################### b) However, if the forwarded port is in listening state, I get the usual 500 error :: ##################################################### 2017/04/15 09:08:21 [error] 16039#16039: *37 invalid URL prefix in ":// 127.0.0.1:5000", client: 182.69.5.226, server: , request: "GET /cgi-bin/webproc HTTP/1.1", host: "1.2.3.4", referrer: " https://1.2.3.4/?upstream_protocol=http" ##################################################### Note that /cgi-bin/webproc is the default location for the upstream-server. Also, to re-iterate, following is the proxy-pass directive :: proxy_pass $arg_upstream_protocol://127. 0.0.1:$forwarded_port; 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? On Sat, Apr 15, 2017 at 1:55 PM, Francis Daly <fran...@daoine.org> wrote: > On Fri, Apr 14, 2017 at 06:42:22PM +0530, Ajay Garg wrote: > > Hi there, > > > When I do the following call :: > > > > https://username:password@1.2.3.4?upstream_protocol=http > > > 2017/04/14 13:03:51 [error] 16039#16039: *1 invalid URL prefix in ":// > > 127.0.0.1:5000", client: 182.69.5.226, server: , request: "GET > > /cgi-bin/webproc HTTP/1.1", host: "1.2.3.4", referrer: " > > https://1.2.3.4/?upstream_protocol=http" > > > What am I missing? > > The request in the log line is not the same as the first request provided. > > What is the output of "curl -v" on the first request? If it is not > exactly what you expect, what does the nginx log say for that one request? > > Good luck with it, > > f > -- > Francis Daly fran...@daoine.org > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > -- Regards, Ajay
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx