[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: PATCH: KHTML - properly send SSL meta data
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-07-28 15:03:34
[Download RAW message or body]

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.

[prev in list] [next in list] [prev in thread] [next in thread]