On Wed, Dec 16, 2015 at 03:38:51PM -0500, no.1 wrote: Hi there,
> thanks for the details. I guess the trick is first to bypass a QNAP internal > redirect to the NAS GUI (if possible or to integrate it on the first > request). And second to to adapt the login request the right way. (btw: I > try to avoid to change the qnap service, because of the regular QNAP > firmware updates.) You have a good reason not to change the qnap service itself to be below /nas/; that's fine. You're reluctant to use nas.home.example.com to access the qnap service while using owncloud.home.example.com to access the owncloud service -- that's fine too. You may find that things do not work smoothly in that case, but that's what happens. > For the first topic the internal network traffic analysis from Firefox shows > a lot of GET requests and some POST regarding the login: I'm unsure what precisely you are doing to see these responses. It will probably be easier for someone else to replicate what you are seeing, if you can write down exactly what you do and exactly what you see. For example, starting from a shell on the nginx server (the RasPi machine), what responses do you get when you type each of curl -v http://qnap:8080/ curl -v http://qnap:8080/redirect.html?count=0.xxxx curl -v http://qnap:8080/cgi-bin/QTS.cgi?count=yyyyyy curl -v http://qnap:8080/cgi-bin/ curl -v http://qnap:8080/photo (using the urls that you mention)? I suspect that some will be HTTP 301 or 302 redirects, and some will be HTTP 200 responses with content which includes links to other things. nginx's proxy_redirect can modify the http headers, but not the body content -- so whether the application works easily through a reverse proxy system depends on the application. The results from the above might hint at whether the application works easily through a reverse proxy. > So I tried it with http://qnap:8080/cgi-bin/login.html locally, which leads > successfully to the login page http://qnap:8080/cgi-bin/. Changing the > location part as suggested into: > location ^~ /nas/ { > proxy_pass http://qnap:8080/cgi-bin/; > proxy_set_header X-Real-IP $remote_addr; > } > and trying the address https://example.com/nas/login.html results in a > broken login page with a lot of 404 errors. It is possible that location ^~ /nas/ { proxy_pass http://qnap:8080/; } will be enough, where you would request /nas/cgi-bin/login.html; but it all depends on your qnap application. > Can anybody tell why it stays on external requests on content type "html"? > Does it have to do something with Cache-Control? One request gets one response; that response content may lead to more requests for css and jpg and the like content. If the initial response is 404, there is unlikely to be a follow-up request. Good luck with it, f -- Francis Daly [email protected] _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
