[Interest] bug with # in URL when using setUrl?

[Larry Martell]

On Tue, Mar 15, 2016 at 12:45 PM, Thiago Macieira
<thiago.macieira at 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?