PATCH: Better cross-domain cookie detection [BR 66090]
Dawit A.
adawit at kde.org
Tue Dec 2 14:26:22 GMT 2003
On Monday 01 December 2003 07:53, Waldo Bastian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon December 01 2003 13:39, Dawit A. wrote:
> > However, before committing this I have to track down a bigger problem.
> > For some reason none of the meta data set in KHTMLPart::openURL makes it
> > down to the http io-slave. The weird thing is the ones set in the loader
> > do get there everytime. Have no clue why and I am attempting to debug
> > it...
>
> The request is usually actually started by doing:
> emit d->m_extension->openURLRequest
>
> Then konqueror starts the job, looks at the mimetype that comes back and
> decides to hand the URL over to the khtml_part//openURL which then starts a
> new job which will get the original slave+response handed over by the
> scheduler.
Ahhh... Good thing you mentioned that. I found the problem. It is konqueror's
attempt to detect the mimetype that was causing this issue. The
"cross-domain" meta-data needs to be added to BrowserRun::scanFile and
possibly to KRun::scanFile as well. That fixes my problem.
However, after several hours of investigation, I am completely dumb founded
about how retrieving a URL works when it is a result of the user typing into
the location bar. Konquerror makes the original request. Determines the
content-type using BrowserRun which puts the job on hold. Konqueror uses the
mime-type information to invoke the appropriate part/view/app to handle the
request, in our case KHTMLPart. KHTMLPart then invokes openURL which makes
another KIO request I guess using the io-slave on hold. This is where it gets
interesting. I see the meta-data set by KHTMLPart::openURL getting all the
way down to SlaveBase, grand-parent of kio_http :) However, so far as I can
tell no re-request is made by kio_http! Even if "Use Cache" is completely
disabled! I presume this is by design to avoid duplicating each request,
right ? This behavior also results in all the meta-data sent by KHTMLPart to
be completely useless (ignored). For example, doing View->Document
Information absolutely shows nothing here. Hmm...
--
Regards,
Dawit A.
"Preach what you practice, practice what you preach"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cross-domain-3.diff
Type: text/x-diff
Size: 8464 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031202/1f883fd4/attachment.diff>
More information about the kde-core-devel
mailing list