View Full Version : QWebPage using invalid base URL for loading with QNetworkReply proxy [SOLVED]

18th February 2011, 14:25

I'm creating a browser that uses a custom protocol, which could for example be accessed by the URL scheme 'custom', with a URL like


I have a QNetworkAccessManager subclass which detects all the requests using that scheme, and creates different QNetworkReply subclasses based on the rest of the content in those URLs.

One of these custom QNetworkReply objects creates a QNetworkRequest object inside it, passing it a regular HTTP URL to download (I'm testing with "http://google.com"), and initiating a download with my QNetworkAccessManager subclass.

The QNetworkReply subclass then acts as a proxy for this request made internally, and the QWebFrame seems to load the main HTML content of the Google home-page just fine.

The problem comes when it tries to load external content. I'm outputting subsequent requests made to my QNetworkAccessManager subclass (in the createRequest() override ... following the initial custom://foo/bar request), and get things like



"custom://foo/extern_js/f/CgJlbhICbnogACswRTgALCswWjgALCswDjgALCswFzgALCswJz gALCswPDgALCswUTgALCswCjgAQB0sKzAWOAAsKzAlOM-IASwrMEA4ACwrMEE4ACwrME04ACwrME44ACwrMFQ4ACwrMGk4A CwrMBg4ACwrMCY4ACyAAjSQAjA/_uiD8tdcvWc.js"

So it appears to be using the original URL as a base URL for loading the rest of the page content, which is incorrect; it should of course be http://google.com/intl/en_com..., http://google.com/images/srpr/nav..., etc.

Is there anything I can return from the reply to make the QWebFrame use the right base URL? I did consider splicing the returned data with a <base href="<requested URL base directory as determined by QNetworkReply subclass>"/> put in-between the downloaded <head> element, but this seems messy, and I'm not sure what weird behaviours this might cause later.

Are there any headers that can be set that will make the QWeb[Page/Frame] look in the right place for external content?

Any and all assistance is welcomed.


Solved. There was a much simpler solution to this, don't proxy QNetworkReply at all, and just set a 302 redirect status code on the QNetworkReply subclass to redirect to the appropriate URL for the initial request.