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