Bug 50644 - [Qt] tagging network replies created by webkit with useful information
Summary: [Qt] tagging network replies created by webkit with useful information
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Enhancement
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2010-12-07 13:59 PST by Robert Hogan
Modified: 2014-02-03 03:10 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Hogan 2010-12-07 13:59:42 PST
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
Comment 1 Alexey Proskuryakov 2010-12-08 00:16:41 PST
Don't onbeforeload events have a target? That would at least provide information about which tag loads the resource.
Comment 2 Benjamin Poulain 2010-12-08 04:25:33 PST
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.
Comment 3 Peter Hartmann 2010-12-08 05:41:13 PST
(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.
Comment 4 Robert Hogan 2010-12-08 11:36:26 PST
(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.
Comment 5 Jocelyn Turcotte 2014-02-03 03:10:29 PST
=== 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.