[webkit-qt] Currently Missing Features with QtWebkit / QNetworkAccessManager

Dawit A adawit at kde.org
Thu Aug 12 21:29:17 PDT 2010


Great, I was also in the process of writing a NetworkRequestFilter class as
part of the KDE KIO::Intergration classes. The way I originally envisioned
the request filter class to work was very primitive and simple with only one
function to be re-implemented by inheriting classes. The following would be
a preliminary signature

class QNetworkRequestFilter
{
public:
   virtual bool allowRequest(const QNetworkRequest& request) const = 0;
};

And ofcourse add functions to QNetworkAccessManager so it can use the
filters... Perhaps the following additional functions ?

bool requestFilteringEnabled() const;
setEnableRequestFiltering(bool enable);
addRequestFilter(const QNetworkRequestFilter *);
removeRequestFilter(const QNetworkRequestFilter *);

To retain current behavior QNetworkAccessManager will not perform any
request filtering, i.e. requestFilteringEnabled() will return false. This
should make it possible for multiple application level plugins to filter
requests without breaking each other's implementation.

Of course Benjamin has suggested another approach and if that works for
prevents the above scenario, then the need for such a class might be a moot
point...


On Wed, Aug 11, 2010 at 8:40 AM, Richard Moore <rich at kde.org> wrote:

> On Fri, Jul 9, 2010 at 8:38 AM, Dawit A <adawit at kde.org> wrote:
> > QNAM
> > ---------
> > 1.) Add a new class for filtering requests without having to inherit from
> > QNetworkAccessManager, something like a QNetworkRequestFilter class,
> which can
> > be added and removed from QNAM to be used as a request filter.
>
> I've started working on a QNetworkCustomReply class which I'll blog
> about once I've finished (and then see if it can be worked up as a
> MR). I'm still thinking about how a QNetworkRequestFilter would look.
>
> Cheers
>
> Rich.
>
> >
> > Regards,
> > Dawit A.
> >
> >
> > On Thursday, July 08, 2010 16:20:17 Richard Moore wrote:
> >> These are the issues I'm aware of with the QtWebkit/QNAM combination
> >> as a platform for browsers. It's possible that some of these issues
> >> are incorrect and are supported somehow I'm not aware of, if so please
> >> say so as that would be great! Note, don't take this as a criticism,
> >> it's intended more as a way of organising what remains to be done.
> >>
> >> * No support for OCSP (online certificate status protocol)
> >>
> >> * No support for SNI (server name indication) see QTBUG-1352
> >>
> >> * No support for EV certificates
> >>
> >> * No support for DNS pinning (a way of avoiding DNS rebinding attacks)
> >>
> >> * Incorrect case-sensitivity in MIME type handling (webkit bug #28654).
> >>
> >>   This one is waiting on me (or someone else) finding time to write
> >> the test cases.
> >>
> >> Anyone got anything to add to this todo list?
> >>
> >> Cheers
> >>
> >> Rich.
> >> _______________________________________________
> >> webkit-qt mailing list
> >> webkit-qt at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> > _______________________________________________
> > webkit-qt mailing list
> > webkit-qt at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20100813/d60081c1/attachment-0001.html>


More information about the webkit-qt mailing list