[Interest] bug with # in URL when using setUrl?
Thiago Macieira
thiago.macieira at intel.com
Tue Mar 15 17:45:50 CET 2016
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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest
mailing list