General Questions for an asp guru

[Crash1hd]

Ok I have a couple of questions not all of them are asp related but majority of them are so that is why I am posting them here

1. The difference between useing global.asa or anything.inc? why use one over the other?

2. Useing anything.inc or anything.js which is better for a table of graphics header same header file per page? which would load faster and better?

3. Useing header domains for example http://header.mysite.com or http://www.mysite.com/header/ which is better and why? remembering that I am useing a preload for images!!!

4. How to offer a user to stay logged into a website useing sessions and inc or asa files, and not use a cookie file? if possible if you have to use a cookie file how to encrypt the clearance lvl so that a user cant just change it in the cookie file and get more access!

[raf]

Well, here's my opinion (for what it's worth)
About 1 : the global.asa is a file that is called and processed automatically on 4 events (when the application is started or ended + when a new session is started or ended). So the first time a client requests an asp-page from your app, the global.asa is called and the session on start sub is processed. If the session is abandonned or times out, the session on end sub is processed. Automatically. An include (SSI) need to be included in the file to get processed (--> should be filespecific and should contain code that needs to be ran if the file is requested or if a condition in the files script is passed). They in fact have nothing to do with eachother (not that i can think of) and work differently for different purposes. Global.asa needs to be placed in the application-root, include can be placed 'anywhere'.
About 2 : don't quite get that. Don't think there is a performance difference cause it has another extension (if they are both SSI). The content of the file will be buffered and parsed + result will be transfered to client. So the loading in the browser should be exactly the same. I would use a framepage to not having to load the header on each page, but lotts of people don't like frames.
About 3 : better? if i'm not mistaking, the first is a subdomain of mysite.com. So possibly, that is better for people who just type in that url (header.mysite.com), since the index-page for that subdomain will then be called. If they just enter www.mysite.com , then the indexpage of mysite.com will be called and the user will not end up at the homepage of the subdomain. Don't quite see what that has to do with preloading the images ? As far as i know, this only means nothing will be shown in the browser until all images or loaded.
About 4 : here's a thread about that. (it's in fact started by yourself and i thought your question/problem was dealt with ?)
http://www.codingforums.com/showthread.php?s=&threadid=19243
IIS always opens a session. But you can use the sessionobject to store login-information in sessionvariables, and then use an include at the top of each page to check if the client is logged in (and if he has permission to see that page). You can use the global.asa file to destroy the session object (or just clear some sessionvariabels in case the client wants to log in with another profile) when the user ends the session. Calling the sessionobject causes some load on the webserver. Working with cookies is probably less taxing on the server (?) but less save (?). If you have hundreds of simultanious users, you'll probably can't rely on the sessionvariabels permissionchecking for each page. I hope to get that problem sometime in the future :)
Note : IIS isn't always bulletproof in it's sessionmanagement. I remember giving a course with some pc-exercises in an asp app. Each course, some clients got the 'wrong' info. That is, info that there neighbours requested. I think it was because we used a passthrough server and ISS messed the sessions up because they all got the same IP number and had simultanious request or so.
Whatever the problem was, be aware that when an app runs like that (mostly on an intranet), sessions can be mixed up and users can get data that was meant for others ... But other that in that situation, i never experienced it myself so it could be down to a bably configured server.
I think the safest way is doing your sessionmanagement using a db, where you store some clientinfo(like IP, userID etc), but this also creates some load.
Cookies can always be read and modifyed, unless your really going to encrypt and decrypt the values, but this gets complicated and isn't required for most apps.