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

Konstantin Tokarev annulen at yandex.ru
Wed Mar 16 11:29:16 CET 2016



16.03.2016, 02:15, "Larry Martell" <larry.martell at gmail.com>:
> 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?

QtWebKit has developer tools. You need to create QWebInspector, set QWebPage to it,
and enable QWebSettings::DeveloperExtrasEnabled

You will get error console, JS debugger, and other goodies.

-- 
Regards,
Konstantin



More information about the Interest mailing list