Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
In ASPese, I'm only familiar with "Application" as an object with the
properties, collections, methods and events that best fit what I was
trying to describe, and have nothing to do with the server being
reset. So, it's entirely possible that I misunderstand the structure
in the way that you describe, but then again, I'm here only to learn
such things.
That is not the application but the application-object, that lives as long
as the application lives, so until the application is reset.
[usually coinciding with the serever reset, unless you have a special and
uncommon reason to reset the application otherwise.
Well, that brings me back to earlier conversations here regarding what
the boundaries of a "page" might be in ASP. What you are calling a
"page" here is almost the antithesis of what Bob and others have
called a "page", and would not qualify as a "page" by the definitions
they presented for several reasons.
Call "Members.asp" what you like, a page, a file, but it is not an
application.
Activities controlled by that
application do not change the URL presented to the browser
regardless of the actual location of the page being rendered, which
is how I understood the OQ.
How can activities [What is "activities" anyway?]
be controlled by a page?
What I mean by "activities" is the users' interaction with the site,
such as viewing content, uploading/downloading files, etc. If there is
a more appropriate term, please advise.
"user interaction" is a good word.
Your definition of a "page" differs from both the HTML definition and
Bob and others' definition of ASP pages, so I have no idea what you
mean by this comment. But, since I specifically said "HTML pages",
those are defined by HTML structures (head, body, table, etc.) and
they most certainly can be "contained" in VB/JScript functions.
You miss the point.
A function in asp is a scripting construct.
How can a bot _determine_ the URL under those circumstances?
Simple, it reeds that UPRL in the stream of another page, for instance a
frames page.
We aren't talking about the same thing. I'm referring to usage such
as: ========================================
<%
FUNCTION MainPage
That could be done, never seen that before,
it looks like an ingenious way to fill a variable.
%>
<head>
<title>Welcome <%=Session.Contents.Item("WhoIs")%></title>
</head>
<frameset rows="155,*" border="0" framespacing="0" frameborder="no">
<frame src=<%=HeaderPage%> name="Header" noresize scrolling="no">
<frame src=<%=BodyPage%> name="Pages" noresize>
better enclude the strings with quotes, single or double:
<frame src='<%=BodyPage%>'
for two reasons:
1 if the string value of the variable contains a space,
you would be in big trouble.
2 to give a better feeling that it is a string that is returned and
inserted into the rendered html. This string contains the URL to be used
for that frame.
</frameset>
<noframes>
</body>
</noframes>
Illogical to include a body close as a noframe
</html>
<%
END FUNCTION
%>
========================================
Where "HeaderPage" and "BodyPage" are two other functions in an
Ah, yes. strange funtions they are.
include file containing HTML code,
No, they are not include files, but clientside URL's of the frames.
They are easily readable in the frames page by a bot.
An include file in asp, being a serverside command, goes:
st as does this function. In such
a case, AFAICT, the only thing visible is something like
whatever.com/members.asp, regardless of the location of the content or
"activity" being accessed by the user. I thought this might be what
the OQ was referring to.
So, I was curious about how a bot might extract than this without
accessing the ASP code?
Simple, the bot does not read:
<frame src='<%=BodyPage%>' name="Pages" noresize>
as that does not leave the server, but the rendered string:
<frame src='/pages/myPage27.asp' name="Pages" noresize>
and so the bot will index:
http://yourDomain.orig/pages/myPage27.asp
as a seperate page, breaking the cloaking.
======================================================
Remember, these are completely different:
SERVERSIDE:
"asp-include"
<!--#include file ="aFile.asp"-->
a file containing a textstring is included in the asp source,
before any rendering by the asp-interpreter.
"server transfer":
<% server.transfer "/blah/afile.asp" %>
The asp-interpreter continues rendering
with the text content on another file.
CLIENTSIDE:
"frame-page":
<frame src='/pages/myPage27.asp'>
a htmltrendering of an .asp file is used by the browser
as the content of a frame.
If part of that is constructed from asp-variable contents
does not matter in the sense how the browser sees the frames page,
so:
<% myVar = "rc='/pages/" %>
<frame s<% = myVar %>Page27.asp'>
renders exactly the same html as:
<frame src='/pages/myPage27.asp'>
