A C++ application that embeds WebKit using Qt utilizes HTML content with a bespoke URI scheme that is intercepted and processed separately. The URI in the content is of the form myscheme:///blah.blah.blah but when the user clicks on an anchor tag with this HREF value, the url passed in via the QNetworkRequest parameter in the overridden acceptNavigationRequest function appears as myscheme:/blah.blah.blah (i.e. 2 of the 3 slashes are removed). To test, create a page with the following fragment of HTML: <a href="myscheme:///blah.blah.blah">External link</a> and in your application: bool MyWebPage::acceptNavigationRequest(QWebFrame* frame, const QNetworkRequest& request, NavigationType type) note that the request.url() is "myscheme:/blah.blah.blah" and not "myscheme:///blah.blah.blah" as expected. Only able to try this on Windows XP with an open source build of WebKit 4.5.0.
I see how this can be unexpected, but does anything in RFC 3986 (or some other standard) say that this is wrong?
I haven't read the RFC so the behavior may well match what's defined in that document. If that's the case, would it be overkill to provide a url() and rawUrl() accessors?
Perhaps, but my question wasn't rhetoric - it may well be that our behavior is incorrect.
Please provide a testcase (a small Qt app) that does what the description says, to help us verify this issue. Thanks.
Will do - might take me a little while as I'm not very familiar with Qt but I should be able to rip out the bits that illustrate what I'm talking about.
This is a known issue in Qt's QUrl See http://bugreports.qt.nokia.com/browse/QTBUG-8701 Resolving as won't fix to mean it is tracked with Qt.