[Webkit-unassigned] [Bug 18608] [Gtk] WebKitNetworkRequest needs to be finished

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=18608





------- Comment #21 from gns at gnome.org  2008-12-27 14:47 PDT -------
(In reply to comment #20)
> (In reply to comment #18)
> > Created an attachment (id=22557)
 --> (https://bugs.webkit.org/attachment.cgi?id=22557&action=view) [review] [review]
> > proposed patch
> 
> Since we plan to actually expose libSoup API now, would it make sense to expose
> a SoupMessage here? It looks like WebKitNetworkRequest to some extend reflects
> what a 'message' does. While I doubt that either one can replace the other, a
> 'request' might for instance contain a 'message', for things like the method,
> uri, body and headers. But that's only an idea, it might be less good an idea
> in practise.
> 
> Another point is caching, we only have memory caching. It might be good to
> figure out what the plan is, ie. if libSoup is going to feature caching, or if
> we rely on a proxy server to do that, or if WebKit itself should take care of
> it. And maybe refrain from introducing an option unless we know what it is
> going to affect.
> 

I like the idea. Though I believe that we actually need to have the Message
become a member of ResourceRequest (or ResourceHandle?) itself, and not be
created in ResourceHandle::startHttp. We also need to figure out how to deal
with non-HTTP stuff; should we have some kind of handling for that in
ResourceRequest and WebKitNetworkRequest?

This could be implemented in a way that the SoupMessage will only be
instantiated when a .soupMessage() accessor method is called in
ResourceRequest, and the good thing is this allows our users to access the
SoupMessage (or GFile, in case of a local request, which will probably force us
to decide on this earlier?) which will be used by the Soup backend, at
willSendRequest already.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.