[Qt] tagging network replies created by webkit with useful information

• Component: WebKit Qt
• Status: RESOLVED INVALID

[Robert Hogan]

On 12/03/2010 06:38 PM, ext Piotr Dobrogost wrote:
> I'm creating a screen scraper. The information I'm looking for come in response to ajax calls so I need to monitor all ajax calls and check incoming data. To do so I need to know if an incoming reply is the reply to ajax request or not.
> I'd like to know if there were any thoughts on tagging each QNetworkReply created by webkit (QNetworkManager of QWebPage) with some additional information describing the request? In my case this would be information if it originates from XmlHttp object but mgoetz on #qt-labs suggested other information like type of a resource; script, image etc.

There is no such tags currently. I also think that would be useful.

Such information is needed when implementing filters for AdBlock, this 
cannot be done with the current implementation.

For example ( see http://adblockplus.org/en/filters ):
  * script — external scripts loaded via HTML script tag
  * image — regular images, typically loaded via HTML img tag
  * xmlhttprequest — requests started by the XMLHttpRequest object

Using http://doc.trolltech.com/4.5/qnetworkrequest.html#Attribute-enum
is one possible way of doing this. QtWebKit would tag the request depending on the origin of the request.
This same problem was solved in the case of originating frames at: https://bugs.webkit.org/show_bug.cgi?id=29975

[Alexey Proskuryakov]

Don't onbeforeload events have a target? That would at least provide information about which tag loads the resource.

[Benjamin Poulain]

I think we should avoid using QNetworkRequest::attribute(). Attributes are already the fallback option to put stuff and got really messy over time.

What about QString QNetworkRequest::requestOriginType()? The strings give us infinite flexibility when releasing WebKit, and would not tie QtNetwork to WebKit related type of work.

[Peter Hartmann]

(In reply to comment #2)
> I think we should avoid using QNetworkRequest::attribute(). Attributes are already the fallback option to put stuff and got really messy over time.
> 
> What about QString QNetworkRequest::requestOriginType()? The strings give us infinite flexibility when releasing WebKit, and would not tie QtNetwork to WebKit related type of work.

I think a new QNetworkRequest::Attribute value would be the right place for this, to avoid adding a new method in QNetworkRequest. Then we could still decide whether we want this public (+ documented), undocumented or as a user value (the last option is probably a bad idea).

The benefit of QNetworkRequest::Attribute that I see is that if this is just a Webkit-only use case, we don't need to document the value for the new Attribute enum.

[Robert Hogan]

(In reply to comment #3)
> (In reply to comment #2)
> > I think we should avoid using QNetworkRequest::attribute(). Attributes are already the fallback option to put stuff and got really messy over time.
> > 
> > What about QString QNetworkRequest::requestOriginType()? The strings give us infinite flexibility when releasing WebKit, and would not tie QtNetwork to WebKit related type of work.
> 
> I think a new QNetworkRequest::Attribute value would be the right place for this, to avoid adding a new method in QNetworkRequest. Then we could still decide whether we want this public (+ documented), undocumented or as a user value (the last option is probably a bad idea).
> 
> The benefit of QNetworkRequest::Attribute that I see is that if this is just a Webkit-only use case, we don't need to document the value for the new Attribute enum.

So it would just be documented as 'reserved' and the available range for user attributes decreased by one?

I guess the number of sources we want to tag would increase over time. Would that not become cumbersome? It would be nice if we only had to touch Qt once for this and could extend it within QtWebKit thereafter.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.