On Tue, Mar 15, 2016 at 12:45 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > On terça-feira, 15 de março de 2016 12:04:34 PDT Larry Martell wrote: >> > To make matters short, these two URLs are different: >> > >> > http://foo.bar.com:8000/#/workitem/12345 >> > >> > scheme = http >> > authority = foo.bar.com:8000 >> > path = / >> > fragment = /workitem/12345 >> > >> > http://foo.bar.com:8000/%23/workitem/12345 >> > >> > scheme = http >> > authority = foo.bar.com:8000 >> > path = /#/workitem/12345 >> >> Not quite. > > Yes, quite. There's absolutely not ambiguity or room for discussion in what I > said above. > > It may not be your issue, but the decomposition above is not up for discussion > :-) > >> When http://foo.bar.com:8000/#/workitem/12345/abcd is sent by the >> client (which is what happens on a Mac) what the server sees is: >> >> POST /workitem/12345/abcd > > That is wrong. The server should see > > GET / > > As I said above, this URL decomposes to a path of "/". Calling > QWebView::setUrl() should also trigger a GET, not a POST. > > Now, you said something about JS. My guess is that the JS code you downloaded > with the setUrl() is doing something with the fragment and downloading more > data, via POST. That means the problem is between the JS engine and code, the > DOM structure (which should have the fragment in the window.location object) > and the webview.
I've learned some more about this but I still don't totally understand it nor have I fixed the bug. The nginx config routes requests to http://foo.bar.com:8000 to code that downloads the Angular JS code to the client. When a # is in URL the JS code consumes the request and sends out 3 requests of its own to a different port. The bug I am trying to fix is that on some clients it appears that the http://foo.bar.com:8000 never gets sent. I say 'appears' because what I see is that the 3 requests sent by the JS code never happen. But debugging the Qt app showed me that the code that sends it was always being executed and the url was always properly formed. Then my next thought was that even though the Qt code appeared to be sending it, it wasn't making it out on the wire. So I downloaded wireshark and monitored the traffic. But even on the working systems I did not see the 8000/# request go out. So that led me to these questions: -What runs the JS code on the client? -Is there a cache for the JS code and is it the case that 8000/# will only actually go out on the wire if the routeProvider code is not present on the client? -How can I debug the Angular code? _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest