From kfm-devel Sat Jul 28 15:03:34 2001 From: Dawit Alemayehu Date: Sat, 28 Jul 2001 15:03:34 +0000 To: kfm-devel Subject: Re: PATCH: KHTML - properly send SSL meta data X-MARC-Message: https://marc.info/?l=kfm-devel&m=99633280007489 On Saturday 28 July 2001 10:34, George Staikos wrote: > On Saturday 28 July 2001 10:19, Dawit Alemayehu wrote: > > On Saturday 28 July 2001 01:36, George Staikos wrote: > > > On Friday 27 July 2001 23:30, Dawit Alemayehu wrote: > > > > Hi, > > > > > > > > This patch is intended to fix required meta-data not being sent when > > > > clicking a link on an SSL page. > > > > > > I just tried it on https://www.ibm.com and it doesn't pass through > > > the parent frame flag at all still.... > > > > Okay after further investigation, my patch indeed fixes all the remaining > > transmission problems of ssl-* meta-data except in one case. And that > > is whenever khtml tries to download embeded images in a web page, or > > external CSS files... anything that is done through loader.*. I am not > > sure if it is even necessary to set the meta-data tags under these > > circumstances. > > Those are the ones that were broken :) And yes, we do need those too. > This is particularily important for the main_frame thing since we dont' > want to give initial-load errors on each image. Then the same thing that was implemented in KonqRun have to be done in in the loader: khtml/misc/loader.cpp. Sometimes there is a price to pay for having such a flexiable design :) Hmm... I just thought of an exterme case. Wouldn't doing this cause the dialog box to appear if the image/script file/css file to be retrieved has a different URL than the current one. That is the page is SSL or non-SSL and one of these resources is the opposite ? Should the dialog box be shown under such circumstances ? > > Now the reason why the warnings are not activated is a completely > > different matter/bug. The code in KonqRun::scanFile(), when attempting > > to determine whether or not SSL was in use, was incorrectly using the > > current URL which of course is wrong. The patch below fixes that. > > However, I have no idea why the opposite does not work. That is the > > warning when leaving an SSL page to a non- SSL page. I'll leave that one > > up to you since I need to get some rest now... :) > > It's commented out. :) I have to relocate it. Ah okay... :) Regards, Dawit A.