[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