On Fri, Oct 04, 2019 at 03:36:13PM -0400, Alex Med wrote: Hi there,
Thanks for the extra information. There are a few different things in here, but there is one that stands out as probably being a "quick fix" that should allow the rest to be tested separately... > Your Question # 1 > ----- > then the requests for /dwr/interface/CategoryAjax.js, > /dwr/interface/HostAjax.js, and /html/images/languages/gh_TW.gif are > served from the first location, not the second. > > So - I'm not seeing what you are reporting. > > When you do a "curl -i" for /dwr/interface/CategoryAjax.js, what response > do you get? > > HTTP 200, HTTP 301, something else? > --- > > Answer to Your Question: > > I get a 401 error not authorized if I use curl. Ok; that suggests that it *is* being handled in your location#1, which is what is wanted. That's good. > The errors are being generated because nginx is lowercasing JsonTags and > CategoriesServlet. > > If I do a curl: > > curl -i http://example.com/JsonTags > HTTP/1.1 301 Moved Permanently > Server: nginx > Date: Fri, 04 Oct 2019 19:21:32 GMT > Content-Type: text/html > Content-Length: 178 > Connection: keep-alive > Location: http://example.com/jsontags Yes - that is because that's what your config asks it to do. Because... > If I write http://example.com/API/ or http://example.com/API they are > lowercased, they should not be lowercase because it > should be served by location #1 which makes the path case insensitive with > the "~". No. "~" means "this is a regex location". "~*" would be "this is a case-insensitive regex location". http://nginx.org/r/location If you change your config to use "~*", does that make things do what you want? (Note: your location#1 will not match "/API", because that regex location needs two slashes. So /API will probably be lowercased to /api, and /api will probably be handled in location#3.) > I also get this error: WebSocket connection to > 'ws://example.com/api/ws/v1/system/events' failed: Unexpected response code: > 200. This I have been told > that I have to set the proxy pass to localhost rather than IP in order to > work it properly. I have not tested it yet. Websockets have not been mentioned in this mail yet, as far as I know. I suggest: get the rest working first; then sort out websockets. Good luck with it, f -- Francis Daly fran...@daoine.org _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
