>If a page contains a request for gif file and the gif file is a "totally >separate request", how can this file be both part of the request and >not part of the request?
That's easy, Jim. The hypertext markeup that is sent in response to an HTTP command to get it is ONE connection sent in response to ONE separate connection. Each item that is <embed>ed, or otherwise included in like <image src="blah.gif"> is sent as a SEPARATE connection. (Examination of your server logs will show that one request can actually result in the sending of several separate files.) "Server-Side Includes" (used in TF's SPML) can be used to alter this behavior for HTML, by allowing the HTTP server to construct a response to the command that contains a combination of other HTML markup, but any other files such as images, etc would still be sent separately, just as they are on a single HTML page with <Image> tags. I would suggest that you read up on what the HTTP protocol is to get a better understanding.
>On the one hand you seem to be saying that a variable lasts from where >it is defined until the end of a page--that is, that if I define a >variable on a page I can make reference to it anywhere else on that >page--that is easy to understand (whether or not it actually works is a >yet-to-be-discovered experiment)
Once the page is transmitted to the client, the server forgets about the variable, and waits for the next request. This works and I use it extensively on my pages. I wish there was a way to produce more persistent variables, such as being able to use the LOG function to store them to a file, then READ them back in at some other point and perhaps CLEAR them (with subsequent overwrite of the logged data, rather than appending them to the log file.). Such a mechanism would be very handy. I have noticed during initial development that the constructs used to control flow based upon variables (#if, #else, etc.) sometimes were not handled correctly if they were nested, but I think this is fixed.
>On the other hand there seems to be ambiguity ion your response that >calls for this word "request". If a "request" is supposed to last as >long as the page on which it is made, that is a tyestable assertion.
Rusty has included a test page included in the docs that shows just how this works.
>If there is some deeper meaning to this word request, however, I would >appreciate hearing it.
Again, get a text on HTTP to understand fully, the client-server relationships involved, and how a server processes requests from clients. I believe the University of Illinois at Champaign-Urbanna has some very good ones online.
--- Daniel O'Leary, Admin/WebMaster KloneZone Mac - A TeleFinder 5.7 Mac/Windows BBS
