Secure Pages On A Diet

[Deb]

While working on the order forms for the FutureQuest site (and stepping on Terra's toes while he's trying to work on the secure server <grin> ) ... I decided to stop by here to give those of you who have never developed on a secure server before, but are getting ready to, a 'fair warning'.

I tried to use the standard FQuest design on the secure pages -- I learned quickly that this was a very bad idea. With the server encrypting EVERYTHING that is on the page it slows things down quite a bit, add that to the html etc not being compressed as it moves through the modems and I created a nightmare.

I ended up having to re-design all of the pages I want to offer a secure option for and put them on a serious 'diet'.

So if you are getting some pages ready for the secure server as it becomes closer to a reality for you, you will want to remember to keep the images as small as possible and try not to use any images, or anything else, that is not needed.

However long your page takes to load without being on the secure server, you can probably double that time when you put it on the secure server -- keep that in mind as you build http://www.aota.net/ubb/wink.gif

Deb

[Mandi]

What about a graphic that ought to be in the user's cache, like a background common to all the pages on the site? As opposed to unique secure page graphics - like a giant money bag that says, "Click here to send me all your money . . . "

[Terra]

This is from observation from all the work Deb and I were doing on the secure server... It appears that the browser will cache the images and everything in memory during your session... But if you close down the browser and reopen, then you have to pull everything back through again... I believe that this is a security feature of browsers to not aggresively cache secure pages or store them in your hard drive cache...

Consider that you generate a new session encryption/decryption key... If you close your browser, then it has no choice but to regenerate a new session key the next time you connect to that site... Therefore my deductions of everything above... It's almost like not caching a Perl script because it is dynamic in nature... Secure server is dynamic in nature as well, just at a different level/layer of protocol...

--
Terra
--342sd44 3998dlsk3 ls93 l932lcm 048532.--
FutureQuest

[Justin]

Another issue is that a browser cache's files according to URL. So http://domain.com/picture.gif is different from https://domain.com/picture.gif - so the image is reloaded all together. If there is any difference in the URL the browser considers is a different file.

As for the session thing, that depends on how your cache is set up. I have it configured to only check for new versions of a page once per session - this doesn't mean it reloads necessarily, it only means that it will check the last modified date, and if it returns a 304 it will use the cached file (if I'm understanding HTTP correctly...).

But I think the URL thing is the biggie here... also, I think anything used by the secure pages must be located on the secure site (or in the secure directory) in order to maintain the secure status - so it has to be a new copy of the image.

It's probably a combination of all of the above, with the end result being that the secure page on FQ's site takes a long time to load http://www.aota.net/ubb/smile.gif I'm only guessing on most of that, BTW, but it sounds right http://www.aota.net/ubb/biggrin.gif

<update>
I just realized Terra was refering to the browser not caching files because they are secure, not because of their location or whatever. But I did check IE's settings, and you can opt whether it cache's encrypted pages to disk or not - along with a few other SSL options ("Delete saved pages when closed", etc).
</update>

------------------
Justin Nelson
FutureQuest Tech Support


[This message has been edited by Justin (edited 03-16-99).]