469,313 Members | 2,633 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,313 developers. It's quick & easy.

transparent redirection in asp

rvj

if you redirect on an IIS , must the client url address bar always be
updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar

Q2 ... or is this one of the main benefits of the IIS URL rewriter ??

Q3 and am I correct in thinking that search engines would only contain
indexes for http://old.com
Aug 2 '08 #1
33 2306
rvj
what I forgot to ask is
Q4 whether URL rewriter only works within the current domain

http://old.domain.com is rewritten as http://domain.com/new
Q5 are there any other methods of redirection to other domains which are
"hidden" from the client
(other than making serverside http requests and using response.write
to display it)

"rvj" <rv*@rolemodels.netwrote in message
news:uF*************@TK2MSFTNGP02.phx.gbl...
>
if you redirect on an IIS , must the client url address bar always be
updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar

Q2 ... or is this one of the main benefits of the IIS URL rewriter ??

Q3 and am I correct in thinking that search engines would only contain
indexes for http://old.com

Aug 2 '08 #2
Gazing into my crystal ball I observed "rvj" <rv*@rolemodels.net>
writing in news:uF*************@TK2MSFTNGP02.phx.gbl:
>
if you redirect on an IIS , must the client url address bar always be
updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar
Frames, but that's a bad idea. Why would you not want the address bar
updated? Wouldn't you want the user to able to bookmark the new address?
>
Q2 ... or is this one of the main benefits of the IIS URL rewriter ??
If you are talking about http://www.example.com/somepage.asp?
string=long&type=very&something=else&etc=etc changing to
http://www.example.com/somepage1234.html that's a rewrite of a document,
not a domain.
>
Q3 and am I correct in thinking that search engines would only contain
indexes for http://old.com
If a SE gets a 301 then it will make note and change its index
accordingly. This is a lot safer than doing it client side with the
meta http-equivalent element. Of course, if that is the only choice,
then one would want to put a link to the new address in the body of the
document, with instructions to update bookmarks.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Aug 2 '08 #3
"rvj" <rv*@rolemodels.netwrote in message
news:O3**************@TK2MSFTNGP04.phx.gbl...
what I forgot to ask is
Q4 whether URL rewriter only works within the current domain

http://old.domain.com is rewritten as http://domain.com/new
Q5 are there any other methods of redirection to other domains which are
"hidden" from the client
(other than making serverside http requests and using
response.write
to display it)
Your server could make the request to the other server on behalf ot the
client and return the response.

However as was asked by Adrienne, why would you need this?
--
Anthony Jones - MVP ASP/ASP.NET
Aug 2 '08 #4
rvj
Frames, but that's a bad idea. Why would you not want the address bar
updated? Wouldn't you want the user to able to bookmark the new address?
Well one of main reasons for URL rewriter is to allow sites to create easy
to remember URIs which ideally never need changing
when the location changes I think this is also known as URL masking
If you are talking about http://www.example.com/somepage.asp?
string=long&type=very&something=else&etc=etc changing to
http://www.example.com/somepage1234.html that's a rewrite of a document,
not a domain.
Ok I was making a simple example - perhaps a liitle too simple. I'm
assuming the default document
located on http://old..com has been moved to http://new.com.

The issue is how to mask the fact that it has moved. A possible alternative
at the domain level would be to change the DNS
record for old.com to point to new.com. The issue is the same - how to make
the URIs appear to the user to be written in stone

If a SE gets a 301 then it will make note and change its index
accordingly. This is a lot safer than doing it client side with the
meta http-equivalent element. Of course, if that is the only choice,
then one would want to put a link to the new address in the body of the
document, with instructions to update bookmarks.
same issue as above to make bookmarks permanent and also search engine
friendly
as described in
http://msdn.microsoft.com/en-us/libr...(printer).aspx

"Adrienne Boswell" <ar****@yahoo.comwrote in message
news:Xn****************************@69.16.185.247. ..
Gazing into my crystal ball I observed "rvj" <rv*@rolemodels.net>
writing in news:uF*************@TK2MSFTNGP02.phx.gbl:
>>
if you redirect on an IIS , must the client url address bar always be
updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar

Frames, but that's a bad idea. Why would you not want the address bar
updated? Wouldn't you want the user to able to bookmark the new address?
>>
Q2 ... or is this one of the main benefits of the IIS URL rewriter ??

If you are talking about http://www.example.com/somepage.asp?
string=long&type=very&something=else&etc=etc changing to
http://www.example.com/somepage1234.html that's a rewrite of a document,
not a domain.
>>
Q3 and am I correct in thinking that search engines would only contain
indexes for http://old.com

If a SE gets a 301 then it will make note and change its index
accordingly. This is a lot safer than doing it client side with the
meta http-equivalent element. Of course, if that is the only choice,
then one would want to put a link to the new address in the body of the
document, with instructions to update bookmarks.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Aug 3 '08 #5
rvj
Your server could make the request to the other server on behalf ot the
client and return the response.
that was solution I was suggesting >" making serverside http requests and
using
response.write to display it"
However as was asked by Adrienne, why would you need this?
URL to URI migration

"Anthony Jones" <An*@yadayadayada.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
"rvj" <rv*@rolemodels.netwrote in message
news:O3**************@TK2MSFTNGP04.phx.gbl...
>what I forgot to ask is
Q4 whether URL rewriter only works within the current domain

http://old.domain.com is rewritten as http://domain.com/new
Q5 are there any other methods of redirection to other domains which are
"hidden" from the client
(other than making serverside http requests and using
response.write
>to display it)

Your server could make the request to the other server on behalf ot the
client and return the response.

However as was asked by Adrienne, why would you need this?
--
Anthony Jones - MVP ASP/ASP.NET


Aug 3 '08 #6
"rvj" <rv*@rolemodels.netwrote in message
news:uE**************@TK2MSFTNGP02.phx.gbl...
>
Frames, but that's a bad idea. Why would you not want the address bar
updated? Wouldn't you want the user to able to bookmark the new address?

Well one of main reasons for URL rewriter is to allow sites to create
easy
to remember URIs which ideally never need changing
when the location changes I think this is also known as URL masking
I've not some across that term before. Sites that create easy to remember
URLs that they transform to another URL for its own consumption use URL
rewriting and don't normally modifiy the authority element of the URL, only
the path and search elements. This transform is not seen by the client
since it happens only inside the server.

If a server such as IIS is supporting multiple sites it may be possible to
use a URL rewriting ISAPI filter to divert requests from to one host name to
another as long as both are being supplied by the server.
If you are talking about http://www.example.com/somepage.asp?
string=long&type=very&something=else&etc=etc changing to
http://www.example.com/somepage1234.html that's a rewrite of a document,
not a domain.

Ok I was making a simple example - perhaps a liitle too simple. I'm
assuming the default document
located on http://old..com has been moved to http://new.com.

The issue is how to mask the fact that it has moved. A possible
alternative
at the domain level would be to change the DNS
record for old.com to point to new.com. The issue is the same - how to
make
the URIs appear to the user to be written in stone
You are correct modifying the DNS and have whatever server is supplying
new.com supply its content as old.com as well would work. Is this not a
solution you could use?

However it still isn't clear why the URL in the browser must not change.
Why not use a permanent redirect?
--
Anthony Jones - MVP ASP/ASP.NET
Aug 3 '08 #7
rvj
However it still isn't clear why the URL in the browser must not change.
Why not use a permanent redirect?
Maybe but really at the moment I'm still fact finding
I'm just trying to see what options are available and pick the most
appropriate

Thanks
"Anthony Jones" <An*@yadayadayada.comwrote in message
news:uB**************@TK2MSFTNGP02.phx.gbl...
"rvj" <rv*@rolemodels.netwrote in message
news:uE**************@TK2MSFTNGP02.phx.gbl...
>>
Frames, but that's a bad idea. Why would you not want the address bar
updated? Wouldn't you want the user to able to bookmark the new
address?

Well one of main reasons for URL rewriter is to allow sites to create
easy
>to remember URIs which ideally never need changing
when the location changes I think this is also known as URL masking

I've not some across that term before. Sites that create easy to remember
URLs that they transform to another URL for its own consumption use URL
rewriting and don't normally modifiy the authority element of the URL,
only
the path and search elements. This transform is not seen by the client
since it happens only inside the server.

If a server such as IIS is supporting multiple sites it may be possible to
use a URL rewriting ISAPI filter to divert requests from to one host name
to
another as long as both are being supplied by the server.
If you are talking about http://www.example.com/somepage.asp?
string=long&type=very&something=else&etc=etc changing to
http://www.example.com/somepage1234.html that's a rewrite of a
document,
not a domain.

Ok I was making a simple example - perhaps a liitle too simple. I'm
assuming the default document
located on http://old..com has been moved to http://new.com.

The issue is how to mask the fact that it has moved. A possible
alternative
>at the domain level would be to change the DNS
record for old.com to point to new.com. The issue is the same - how to
make
>the URIs appear to the user to be written in stone

You are correct modifying the DNS and have whatever server is supplying
new.com supply its content as old.com as well would work. Is this not a
solution you could use?

However it still isn't clear why the URL in the browser must not change.
Why not use a permanent redirect?
--
Anthony Jones - MVP ASP/ASP.NET


Aug 3 '08 #8
"rvj" <rv*@rolemodels.netwrote in message
news:O9**************@TK2MSFTNGP05.phx.gbl...
However it still isn't clear why the URL in the browser must not change.
Why not use a permanent redirect?

Maybe but really at the moment I'm still fact finding
I'm just trying to see what options are available and pick the most
appropriate

Fine, in that case unless you can demonstrate a concrete reason why the URL
in the client browser should not change you should go with a permanent
re-direct.

--
Anthony Jones - MVP ASP/ASP.NET
Aug 3 '08 #9
Hi Adrienne,

Adrienne Boswell wrote:
Gazing into my crystal ball I observed "rvj" <rv*@rolemodels.net>
writing in news:uF*************@TK2MSFTNGP02.phx.gbl:
>>
if you redirect on an IIS , must the client url address bar always be
updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar

Frames, but that's a bad idea.
I've seen this stated in a few places, but the information appeared to be
rather old and I understand why it was iffy to use frames about a decade
ago. Is there any current reason why you feel that using frames is a bad
idea?

--
Neil
Aug 4 '08 #10
Gazing into my crystal ball I observed "Neil Gould"
<ne**@myplaceofwork.comwriting in news:OCkPeDi9IHA.2336
@TK2MSFTNGP03.phx.gbl:
Hi Adrienne,

Adrienne Boswell wrote:
>Gazing into my crystal ball I observed "rvj" <rv*@rolemodels.net>
writing in news:uF*************@TK2MSFTNGP02.phx.gbl:
>>>
if you redirect on an IIS , must the client url address bar always
be
>>updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar

Frames, but that's a bad idea.
I've seen this stated in a few places, but the information appeared to
be
rather old and I understand why it was iffy to use frames about a
decade
ago. Is there any current reason why you feel that using frames is a
bad
idea?

--
Neil
Nothing has changed. Frames are still evil.
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Aug 4 '08 #11

"Adrienne Boswell" <ar****@yahoo.comwrote in message
news:Xn****************************@69.16.185.250. ..
Gazing into my crystal ball I observed "Neil Gould"
<ne**@myplaceofwork.comwriting in news:OCkPeDi9IHA.2336
@TK2MSFTNGP03.phx.gbl:
>Hi Adrienne,

Adrienne Boswell wrote:
>>Gazing into my crystal ball I observed "rvj" <rv*@rolemodels.net>
writing in news:uF*************@TK2MSFTNGP02.phx.gbl:
if you redirect on an IIS , must the client url address bar always
be
>>>updated with the new address. what options are?
Q1 if a user requests http://old.com , is there a method of ASP
redirection to http://new.com
which does not update the client browser's address bar

Frames, but that's a bad idea.
I've seen this stated in a few places, but the information appeared to
be
>rather old and I understand why it was iffy to use frames about a
decade
>ago. Is there any current reason why you feel that using frames is a
bad
>idea?

--
Neil

Nothing has changed. Frames are still evil.

Except, possibly, in an intranet or similarly controlled environment... But
still not my first choice.

--
Mike Brind
MVP - ASP/ASP.NET
Aug 5 '08 #12
Mike Brind [MVP] wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>
"Adrienne Boswell" <ar****@yahoo.comwrote in message
>Nothing has changed. Frames are still evil.

Except, possibly, in an intranet or similarly controlled
environment... But still not my first choice.
I do not see much difference between an "invisible frame" page
[a frames page containing ony one frame],
and an iframe.

I do not consider them evil.

Multiframe framepages are "passé",
as one can do a much nicer job with css, even
with full controll over the scrolling of the framelike parts,
but for a quick and dirty job they are handy now and then,
just because we [few] grew up with frames.

This, however, is off topic on this NG, methinks.

The OQ only applies to the cloacking with an invisible frame,
that is quite handy for having a seperate,
cheap [in the sense of non-asp, perhaps php-only] domain,
pointing to a subpage of your main [asp-enabled] domain.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #13
Evertjan. wrote:
Mike Brind [MVP] wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>
"Adrienne Boswell" <ar****@yahoo.comwrote in message
>>Nothing has changed. Frames are still evil.

Except, possibly, in an intranet or similarly controlled
environment... But still not my first choice.

I do not see much difference between an "invisible frame" page
[a frames page containing ony one frame],
and an iframe.

I do not consider them evil.

Multiframe framepages are "passé",
as one can do a much nicer job with css, even
with full controll over the scrolling of the framelike parts,
Do you have an example of such a usage?
but for a quick and dirty job they are handy now and then,
just because we [few] grew up with frames.

This, however, is off topic on this NG, methinks.
I was curious about any reasons why using frames with ASP would be
detrimental. I have discovered a couple of limitations with this
combination, but in general there seems to be quite a bit of flexibility.
The OQ only applies to the cloacking with an invisible frame,
that is quite handy for having a seperate,
cheap [in the sense of non-asp, perhaps php-only] domain,
pointing to a subpage of your main [asp-enabled] domain.
Yes, and one can also have the page code (HTML or whatever) within a
VB/JScript Function. Only the main ASP appears in the URL window. If there
is a "gotcha" in such an approach, I haven't seen it yet, which is why I
asked.

Neil
Aug 5 '08 #14
Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
Evertjan. wrote:
>Mike Brind [MVP] wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>>
"Adrienne Boswell" <ar****@yahoo.comwrote in message
Nothing has changed. Frames are still evil.

Except, possibly, in an intranet or similarly controlled
environment... But still not my first choice.

I do not see much difference between an "invisible frame" page
[a frames page containing ony one frame],
and an iframe.

I do not consider them evil.

Multiframe framepages are "passé",
as one can do a much nicer job with css, even
with full controll over the scrolling of the framelike parts,
Do you have an example of such a usage?
That would not not have anything to do with ASP.
Why show "passé" clientside technology?
And CSS has it's own NG.
>but for a quick and dirty job they are handy now and then,
just because we [few] grew up with frames.

This, however, is off topic on this NG, methinks.
I was curious about any reasons why using frames with ASP would be
detrimental. I have discovered a couple of limitations with this
combination, but in general there seems to be quite a bit of
flexibility.
It cannot be more detrimental than HTML, as ASP is just a platform for
rendering HTML to the client, and frames live only on the client.
>The OQ only applies to the cloacking with an invisible frame,
that is quite handy for having a seperate,
cheap [in the sense of non-asp, perhaps php-only] domain,
pointing to a subpage of your main [asp-enabled] domain.
Yes, and one can also have the page code (HTML or whatever) within a
VB/JScript Function.
I cannot follow that.
What is a "page code"?
Only the rendered byte stream,
usually html [with clientside scripting and css],
is sent to the client.
Only the main ASP appears in the URL window.
What is a "main ASP"?
ASP is a serverside platform for interpreting VBS/JS/etc.
A file can have any extention [as set in IIS]
to be rendered by the interpreter, not only .asp.

Do you mean DO-main URL?

And "URL window"?
Do you mean "address bar"?

Please be clear.
If there is a "gotcha" in such an approach, I haven't seen it yet,
Good for you.

Cloaking is not ment to be "seen".
It is easily deducted.

And Googlic bot's will not heed the cloaking,
but show the real url.
which is why I asked.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #15
Evertjan. wrote:
Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>Multiframe framepages are "passé",
as one can do a much nicer job with css, even
with full controll over the scrolling of the framelike parts,
Do you have an example of such a usage?

That would not not have anything to do with ASP.
Why show "passé" clientside technology?
And CSS has it's own NG.
OK.
>I was curious about any reasons why using frames with ASP would be
detrimental. I have discovered a couple of limitations with this
combination, but in general there seems to be quite a bit of
flexibility.

It cannot be more detrimental than HTML, as ASP is just a platform for
rendering HTML to the client, and frames live only on the client.
That would be my perspective, as well.
>>The OQ only applies to the cloacking with an invisible frame,
that is quite handy for having a seperate,
cheap [in the sense of non-asp, perhaps php-only] domain,
pointing to a subpage of your main [asp-enabled] domain.
Yes, and one can also have the page code (HTML or whatever) within a
VB/JScript Function.

I cannot follow that.
What is a "page code"?
The HTML (or other) "code" that renders a client side "page".
Only the rendered byte stream,
usually html [with clientside scripting and css],
is sent to the client.
Of course.
>Only the main ASP appears in the URL window.

What is a "main ASP"?
The application.

For example, for our club's site, there are 3 ASP applications chosen by the
login process, and only the application itself appears in the address bar,
e.g. "Members.asp". 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.
>If there is a "gotcha" in such an approach, I haven't seen it yet,

Good for you.
Well, that is why I asked. Hopefully, one of you experienced ASP users might
have seen such a "gotcha", and I'd like to know about it before having to
deduce it. ;-)
Cloaking is not ment to be "seen".
It is easily deducted.

And Googlic bot's will not heed the cloaking,
but show the real url.
Very interesting, but puzzling. For example, consider the above where the
HTML code for a particlular page is in an include file's function, with many
other functions containing other HTML pages. How would a bot render the URL
of a particular on-screen page or even the location of that include file,
unless it can read the ASP code that loads that page?

Best,

Neil

Aug 5 '08 #16
Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>Only the main ASP appears in the URL window.

What is a "main ASP"?
The application.
"Application" in ASPese roughly is all the sessions together since the
last sever reset.
>
For example, for our club's site, there are 3 ASP applications chosen
by the login process, and only the application itself appears in the
address bar, e.g. "Members.asp".
That is not an applicaton, but just a page.
Just inventing word definitions won't do, methinks.
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?
>>If there is a "gotcha" in such an approach, I haven't seen it yet,
>Good for you.
Well, that is why I asked. Hopefully, one of you experienced ASP users
might have seen such a "gotcha", and I'd like to know about it before
having to deduce it. ;-)
>Cloaking is not ment to be "seen".
It is easily deducted.

And Googlic bot's will not heed the cloaking,
but show the real url.
Very interesting, but puzzling. For example, consider the above where
the HTML code for a particlular page is in an include file's function,
I thought I was explaining the problems of frames in html?

Include files just enter text in the bytesteam that will be interpreted
by the ASP-interpreter, and as such are just part of that stream,
and only handy if part of multiple pages are the same again and again.
with many other functions containing other HTML pages.
A function does not contain a page.
How would a bot
render the URL of a particular on-screen page
A bot does not render, it indexes page content by URL.
A bot has no screen, it just parses the incoming stream,
while skipping script and tag content.
URL's cannot be rendered, as an URL is just a text string.
or even the location of that include file,
We were talking cloacking with a frameset with a single frame!
unless it can read the ASP code that loads that page?
===================

ASP can make many different rendered pages all having a single pagename,
depending on:

received form-post values,
received querystring
a session variable value
an application variable value
a date or time of day
etc
etc

A simple example in VBS, not tested:

========= NowAgoToCome.asp =============
<%
toDay = now
if toDay #2008/08/09# then
server.transfer "inTheFuture.asp"
if toDay < #2008/08/01# then
server.transfer "inThePast.asp"
else
server.transfer "nearlyInThePresent.asp"
end if
response.write "This is never written"
%>
================================


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #17
Evertjan. wrote:
Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>>Only the main ASP appears in the URL window.

What is a "main ASP"?
The application.

"Application" in ASPese roughly is all the sessions together since the
last sever reset.
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.
>For example, for our club's site, there are 3 ASP applications chosen
by the login process, and only the application itself appears in the
address bar, e.g. "Members.asp".

That is not an applicaton, but just a page.
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.
>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.
>>>If there is a "gotcha" in such an approach, I haven't seen it yet,
>>Good for you.
Well, that is why I asked. Hopefully, one of you experienced ASP
users might have seen such a "gotcha", and I'd like to know about it
before having to deduce it. ;-)
>>Cloaking is not ment to be "seen".
It is easily deducted.

And Googlic bot's will not heed the cloaking,
but show the real url.
Very interesting, but puzzling. For example, consider the above where
the HTML code for a particlular page is in an include file's
function,

I thought I was explaining the problems of frames in html?

Include files just enter text in the bytesteam that will be
interpreted by the ASP-interpreter, and as such are just part of that
stream,
and only handy if part of multiple pages are the same again and again.
>with many other functions containing other HTML pages.

A function does not contain a page.
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.
>How would a bot
render the URL of a particular on-screen page

A bot does not render, it indexes page content by URL.
A bot has no screen, it just parses the incoming stream,
while skipping script and tag content.
URL's cannot be rendered, as an URL is just a text string.
How can a bot _determine_ the URL under those circumstances?
>or even the location of that include file,

We were talking cloacking with a frameset with a single frame!
>unless it can read the ASP code that loads that page?

===================

ASP can make many different rendered pages all having a single
pagename, depending on:

received form-post values,
received querystring
a session variable value
an application variable value
a date or time of day
etc
etc

A simple example in VBS, not tested:

========= NowAgoToCome.asp =============
<%
toDay = now
if toDay #2008/08/09# then
server.transfer "inTheFuture.asp"
if toDay < #2008/08/01# then
server.transfer "inThePast.asp"
else
server.transfer "nearlyInThePresent.asp"
end if
response.write "This is never written"
%>
================================
We aren't talking about the same thing. I'm referring to usage such as:
========================================
<%
FUNCTION MainPage
%>
<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>
</frameset>
<noframes>
</body>
</noframes>
</html>
<%
END FUNCTION
%>

========================================

Where "HeaderPage" and "BodyPage" are two other functions in an include file
containing HTML code, just 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?

Neil


Aug 5 '08 #18
Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
Evertjan. wrote:
>Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>>>Only the main ASP appears in the URL window.

What is a "main ASP"?

The application.

"Application" in ASPese roughly is all the sessions together since
the last sever reset.
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.
>>For example, for our club's site, there are 3 ASP applications
chosen by the login process, and only the application itself appears
in the address bar, e.g. "Members.asp".

That is not an applicaton, but just a page.
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.
>>>>If there is a "gotcha" in such an approach, I haven't seen it yet,
>>>Good for you.

Well, that is why I asked. Hopefully, one of you experienced ASP
users might have seen such a "gotcha", and I'd like to know about it
before having to deduce it. ;-)

Cloaking is not ment to be "seen".
It is easily deducted.

And Googlic bot's will not heed the cloaking,
but show the real url.

Very interesting, but puzzling. For example, consider the above
where the HTML code for a particlular page is in an include file's
function,
I thought I was explaining the problems of frames in html?

Include files just enter text in the bytesteam that will be
interpreted by the ASP-interpreter, and as such are just part of that
stream,
and only handy if part of multiple pages are the same again and
again.
>>with many other functions containing other HTML pages.

A function does not contain a page.
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 would a bot
render the URL of a particular on-screen page

A bot does not render, it indexes page content by URL.
A bot has no screen, it just parses the incoming stream,
while skipping script and tag content.
URL's cannot be rendered, as an URL is just a text string.
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.
>>or even the location of that include file,

We were talking cloacking with a frameset with a single frame!
>>unless it can read the ASP code that loads that page?

===================

ASP can make many different rendered pages all having a single
pagename, depending on:

received form-post values,
received querystring
a session variable value
an application variable value
a date or time of day
etc
etc

A simple example in VBS, not tested:

========= NowAgoToCome.asp =============
<%
toDay = now
if toDay #2008/08/09# then
server.transfer "inTheFuture.asp"
if toDay < #2008/08/01# then
server.transfer "inThePast.asp"
else
server.transfer "nearlyInThePresent.asp"
end if
response.write "This is never written"
%>
================================
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:
<!--#include file ="/aFile.asp"-->
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'>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #19
Neil Gould wrote:
Evertjan. wrote:
>Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
>>>>Only the main ASP appears in the URL window.

What is a "main ASP"?

The application.

"Application" in ASPese roughly is all the sessions together since
the last sever reset.
That's one way to look at it.
>>
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.
Right, but those objects, etc only persist until the Application is
reset, either via the server being reset or by a change in global.asa.
For example, all application variables need to be repopulated when the
server is 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.
>>For example, for our club's site, there are 3 ASP applications
chosen by the login process,
huh??
and only the application itself
>>appears in the address bar, e.g. "Members.asp".

That is not an applicaton, but just a page.
Well, that brings me back to earlier conversations here regarding
what the boundaries of a "page" might be in ASP.
No, it doesn't - my mind is now boggled. What have I ever said that
would imply, err .... that a page is equivalent to an application?
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.
I don't see why. Many people use the term "page" when they are talking
about a file to be requested from a web server. In your browser's
address bar, you are seeing the address of a page (file) that you are
requesting the web server to serve. If the requested page is mapped to
be processed by the asp.dll. I don't know how you make the leap to say
an "application itself appears in the address bar, e.g. "Members.asp"."

I think the issue is that we have a both a physical and a logical
definition of many of these terms.
The physical definition of a page is a file. It contains code and text.
It can either be served directly via http as html, or processed by
asp.dll to generate html.
The logical definition consists of everything that happens between the
time the physical page is requested and the response ends.
Yes, it is confusing that we use the same term for both concepts but
this is not the only place we do so.

In physical terms, an ASP application consists of all the files (pages)
in a virtual directory, including subfolders.
In logical terms, an ASP application "comes to life", i.e., the
Application object is created, the first time one of the files in the
_physical application_ is requested. If an application_onstart event
handler is present in the global.asa, it will be processed at this time.
The "logical" application stays alive until a change is made to the
global.asa file or the server is reset.
>>>>
Very interesting, but puzzling. For example, consider the above
where the HTML code for a particlular page is in an include file's
function,
with many other functions containing other HTML pages.

A function does not contain a page.
Your definition of a "page" differs from both the HTML definition and
Bob and others' definition of ASP pages,
Now you've got me going back over what I've previously said that could
possibly lead one to the conclusion that a function could contain a
page. Are you talking about a vbscript function? If so, a function is
contained in a physical page, not vice versa.

Hmm, I think I understand what you are trying to say. You have a
physical page containing several functions, each of which generates
different html to be sent to the client. And you are thinking a
different "page" is being sent to the client depending on which function
is run, so you are thinking that each function contains a different
page? Whereas I would be thinking that the same page is being processed
regardless of which function is run, the only difference being what html
is sent to the client.
--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Aug 5 '08 #20
Evertjan. wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
><%
FUNCTION MainPage

That could be done, never seen that before,
it looks like an ingenious way to fill a variable.
>%>
<head>
It can be done, but not the way you did, compare:

<%
function HeaderPage
%>myFile.asp<%
end function
%>

<% BodyPage = "myFile.asp" %>

a correct rendering would "need", Neil:

src = '<% HeaderPage %>'

src = '<% = BodyPage %>'

While

src = '<% = HeaderPage %>'

gives a correct result,
is because vbs is vey lenient to serious errors,
as:

<%
function HeaderPage
%>myFile.asp<%
end function
%>

is the same as:
<%
function HeaderPage
response.write "myFile.asp"
end function
%>
and NOT as:

<%
function HeaderPage
HeaderPage = "myFile.asp"
end function
%>



--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #21
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
Neil Gould wrote:
Evertjan. wrote:
Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:
For example, for our club's site, there are 3 ASP applications
chosen by the login process,

huh??
and only the application itself
>appears in the address bar, e.g. "Members.asp".

That is not an applicaton, but just a page.
Well, that brings me back to earlier conversations here regarding
what the boundaries of a "page" might be in ASP.

No, it doesn't - my mind is now boggled. What have I ever said that
would imply, err .... that a page is equivalent to an application?
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.

I don't see why. Many people use the term "page" when they are talking
about a file to be requested from a web server. In your browser's
address bar, you are seeing the address of a page (file) that you are
requesting the web server to serve. If the requested page is mapped to
be processed by the asp.dll. I don't know how you make the leap to say
an "application itself appears in the address bar, e.g. "Members.asp"."

I think the issue is that we have a both a physical and a logical
definition of many of these terms.
The physical definition of a page is a file. It contains code and text.
It can either be served directly via http as html, or processed by
asp.dll to generate html.
The logical definition consists of everything that happens between the
time the physical page is requested and the response ends.
Yes, it is confusing that we use the same term for both concepts but
this is not the only place we do so.

In physical terms, an ASP application consists of all the files (pages)
in a virtual directory, including subfolders.
In logical terms, an ASP application "comes to life", i.e., the
Application object is created, the first time one of the files in the
_physical application_ is requested. If an application_onstart event
handler is present in the global.asa, it will be processed at this time.
The "logical" application stays alive until a change is made to the
global.asa file or the server is reset.
>>>
Very interesting, but puzzling. For example, consider the above
where the HTML code for a particlular page is in an include file's
function,
with many other functions containing other HTML pages.

A function does not contain a page.
Your definition of a "page" differs from both the HTML definition and
Bob and others' definition of ASP pages,

Now you've got me going back over what I've previously said that could
possibly lead one to the conclusion that a function could contain a
page. Are you talking about a vbscript function? If so, a function is
contained in a physical page, not vice versa.

Hmm, I think I understand what you are trying to say. You have a
physical page containing several functions, each of which generates
different html to be sent to the client. And you are thinking a
different "page" is being sent to the client depending on which function
is run, so you are thinking that each function contains a different
page? Whereas I would be thinking that the same page is being processed
regardless of which function is run, the only difference being what html
is sent to the client.

and here I was thinking F# is hard it seems defining what a page is harder
;)

Page: "The resultant rendering of HTML" thats the best I can do.

Active Server "Page" is a misnomer IMO. I think I've stated somewhere
before that I suspect it would have been Active Server File if ASF hadn't
already been in use and Active Server Script (which is what it really is)
just won't do.


--
Anthony Jones - MVP ASP/ASP.NET
Aug 5 '08 #22
Anthony Jones wrote:
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message

Page: "The resultant rendering of HTML" thats the best I can do.

Active Server "Page" is a misnomer IMO. I think I've stated somewhere
before that I suspect it would have been Active Server File if ASF
hadn't already been in use and Active Server Script (which is what it
really is) just won't do.

That's hard to argue with except that another name for "page" scope is
needed.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Aug 5 '08 #23
Anthony Jones wrote:
>
Page: "The resultant rendering of HTML" thats the best I can do.
That seems to be a definition from a user's POV. And even then, it's a
little dodgy. Does the fact that different text is displayed in a
browser window make it a different page? Even when the url used to
request it is the same? Yeah, I guess from a user's POV the answer could
be "yes".

From this developer's POV, the page is the file used to generate the
html.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Aug 5 '08 #24
Bob Barrows [MVP] wrote:
Neil Gould wrote:
>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.

Right, but those objects, etc only persist until the Application is
reset, either via the server being reset or by a change in global.asa.
For example, all application variables need to be repopulated when the
server is reset.
I agree with this. However, that defines applications as an entity
independent of server resets. Just because the variables are repopulated
does not alter their pupose, does it? As I understand it, the application is
not initialized until it is accessed by a user. Is that wrong, even in cases
where there is no global.asa?
>>>and only the application itself
appears in the address bar, e.g. "Members.asp".

That is not an applicaton, but just a page.
Well, that brings me back to earlier conversations here regarding
what the boundaries of a "page" might be in ASP.

No, it doesn't - my mind is now boggled. What have I ever said that
would imply, err .... that a page is equivalent to an application?
You didn't, and I wasn't suggesting that you did. But, you did say what you
say again later in this message: "Many people use the term "page" when they
are talking about a file to be requested from a web server." This equates
the boundaries of a "page" to that of a file, and others have suggested that
once that file is processed by the server, the "page" has terminated, as
opposed to all of the files that may be handled by what I called the
"application".
>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.

I don't see why. Many people use the term "page" when they are talking
about a file to be requested from a web server. In your browser's
address bar, you are seeing the address of a page (file) that you are
requesting the web server to serve. If the requested page is mapped to
be processed by the asp.dll. I don't know how you make the leap to say
an "application itself appears in the address bar, e.g.
"Members.asp"."
Hey, I'm the first to admit that I do not grasp such a nebulous notion when
a single session can encompass hundreds of "files", yet still be under the
control of a single whatever-you-want-to-call-it (in this case
"Members.asp").
I think the issue is that we have a both a physical and a logical
definition of many of these terms.
The physical definition of a page is a file. It contains code and
text. It can either be served directly via http as html, or processed
by asp.dll to generate html.
The logical definition consists of everything that happens between the
time the physical page is requested and the response ends.
Yes, it is confusing that we use the same term for both concepts but
this is not the only place we do so.
;-)
In physical terms, an ASP application consists of all the files
(pages) in a virtual directory, including subfolders.
That is how I understood it, and tried to use the term. So, when I said that
there are "3 applications", I was referring to 3 (actually more) virtual
directories with subfolders. The first application is the login, that then
determines through redirection which application the user will engage.
In logical terms, an ASP application "comes to life", i.e., the
Application object is created, the first time one of the files in the
_physical application_ is requested.
Again, that is consistent with how I used the term "application". The user
initializes (brings to life) the application by requesting specific files at
login.
If an application_onstart event
handler is present in the global.asa, it will be processed at this
time. The "logical" application stays alive until a change is made to
the global.asa file or the server is reset.
>>>>>
Very interesting, but puzzling. For example, consider the above
where the HTML code for a particlular page is in an include file's
function,
with many other functions containing other HTML pages.

A function does not contain a page.
Your definition of a "page" differs from both the HTML definition and
Bob and others' definition of ASP pages,

Now you've got me going back over what I've previously said that could
possibly lead one to the conclusion that a function could contain a
page. Are you talking about a vbscript function? If so, a function is
contained in a physical page, not vice versa.
Yes, I was referring to a vb/jscript function, but I was referring to an
HTML 'page' as defined by HTML parameters (head, body, etc.).
Hmm, I think I understand what you are trying to say. You have a
physical page containing several functions, each of which generates
different html to be sent to the client. And you are thinking a
different "page" is being sent to the client depending on which
function is run, so you are thinking that each function contains a
different page? Whereas I would be thinking that the same page is
being processed regardless of which function is run, the only
difference being what html is sent to the client.
I can understand that perspective, but then the issue becomes the files
associated with the "application" being separate "pages", as you suggest.
For example, if one file provides the user with code to upload a file, it is
an ASP "page", even in that single activity we can be talking about a number
of different ASP files. Are they separate pages in ASPese? Would they have
unique URLs?

I just want to better understand what is and is not loaded at any point in
time. If the form that initializes an upload process calls an ASP file/page
that controls the process, and that ASP file/page includes the actual code
in a separate file (yes, I understand about includes to that point), when
the completion of that process calls another ASP file/page, I presume that
the previous file/page/include is completely unloaded. Yet, the
"application" -- "Members.asp" -- is still the only thing indicated in the
address bar, and looking at "properties" at any stage does not indicate
anything more than that (which is why I was curious about the ability of
bots to get beyond that without reading the ASP code).

Neil

Aug 5 '08 #25
Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
I just want to better understand what is and is not loaded at any
point in time. If the form that initializes an upload process calls an
ASP file/page that controls the process, and that ASP file/page
includes the actual code in a separate file (yes, I understand about
includes to that point), when the completion of that process calls
another ASP file/page, I presume that the previous file/page/include
is completely unloaded. Yet, the "application" -- "Members.asp" -- is
still the only thing indicated in the address bar, and looking at
"properties" at any stage does not indicate anything more than that
(which is why I was curious about the ability of bots to get beyond
that without reading the ASP code).
You are still not grasping what an application is.

It is the complete us of a website [well sort of]
by all the active users together, which could be thousands.

Any application-object-value is shared by all these users
and could be accessed by asp on each page any user requests.

The application and the aplication-object does not belong to a file/page,
so "Members.asp" is NOT an application.

Each user has a session and a session-object,
that only can be maintained by recognizing the user wit the session-id
cookie. Otherwize each page will be a new session.

You could define the application as a logical collection of all sessions,
though not a collection in the object sense, as the sessions have no access
to eachother's objects but though the application object, [or through a
database or datafile]
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #26
Evertjan. wrote:
Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
[...]
>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.
I was using it as such, specifically via VB/JScript.
>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.
I was trying to demonstrate that no such content is required, and that a
VB/JScript function name is not a URL.
>Where "HeaderPage" and "BodyPage" are two other functions in an
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.
Yes, they are functions in an #include ASP file, and they have no direct
references to a URL to be read by a bot. The references are only to function
names and/or session variables. So, what is the bot going to report?
An include file in asp, being a serverside command, goes:
<!--#include file ="/aFile.asp"-->
Which is exactly how the file I am referring to is included. FWIW, the file
contains only functions with HTML page codes.
>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>
In my haste to present an example, I erred. The actual code uses this form:
<frame src=<%=Session.Contents.Item("MemberHdr")%name="He ader" noresize

Where the session variable is the name of the VBScript function. I wanted to
make it clearer that a function was being called, not a particular ASP file,
and instead may have confused you. Sorry!
as that does not leave the server, but the rendered string:

<frame src='/pages/myPage27.asp' name="Pages" noresize>
There is no such rendered string, AFAICT, as "myPage27.asp" (or any other
individual and independent ASP file containing the HTML to be rendered)
doesn't exist. I'd understand your perspective if such files were being
called, but they aren't.

Best,

Neil

Aug 5 '08 #27
Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
>Simple, the bot does not read:

<frame src='<%=BodyPage%>' name="Pages" noresize>
In my haste to present an example, I erred. The actual code uses this
form: <frame src=<%=Session.Contents.Item("MemberHdr")%name="He ader"
noresize

Where the session variable is the name of the VBScript function.
That could be, but the function is never executed and the function name
is given to the src of the frame to be used as a url string clientside.

You would have to use evil Eval() like:

src = '<% = Eval(Session.Contents.Item("MemberHdr")) %>'

I
wanted to make it clearer that a function was being called, not a
particular ASP file, and instead may have confused you. Sorry!
>as that does not leave the server, but the rendered string:

<frame src='/pages/myPage27.asp' name="Pages" noresize>
There is no such rendered string, AFAICT, as "myPage27.asp" (or any
other individual and independent ASP file containing the HTML to be
rendered) doesn't exist. I'd understand your perspective if such files
were being called, but they aren't.
Nonsense.

Then the frame cannot display it's content as it has none.

A frame only can be used to display content
if it has a valid url string in its src='...',

[or after the src is later applied by clientside code,
or the content is later written into it by clientside code]

You are in error.

Serverside functions do not "function" clientside.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 5 '08 #28
Evertjan. wrote:
Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
>>Simple, the bot does not read:

<frame src='<%=BodyPage%>' name="Pages" noresize>
In my haste to present an example, I erred. The actual code uses this
form: <frame src=<%=Session.Contents.Item("MemberHdr")%>
name="Header" noresize

Where the session variable is the name of the VBScript function.

That could be, but the function is never executed and the function
name is given to the src of the frame to be used as a url string
clientside.
The above frame src (one section of a frame that is itself contained in a
function) is executed via a call to that function.
You would have to use evil Eval() like:

src = '<% = Eval(Session.Contents.Item("MemberHdr")) %>'
No, that isn't what is being used in this case. It is as I described.

>><frame src='/pages/myPage27.asp' name="Pages" noresize>
There is no such rendered string, AFAICT, as "myPage27.asp" (or any
other individual and independent ASP file containing the HTML to be
rendered) doesn't exist. I'd understand your perspective if such
files were being called, but they aren't.

Nonsense.

Then the frame cannot display it's content as it has none.

A frame only can be used to display content
if it has a valid url string in its src='...',
As pointed out above, the target of the src= is a session variable that
contains the name of a VBScript function in an #include file, so the URL is
the original file ("members.asp" in the example). That URL does not change,
regardless of the number of individual ASP files that supply content to that
VBScript function/HTML page or any of the dozens of others in that #include
file.

Neil
Aug 6 '08 #29
Evertjan. wrote:
Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:
>I just want to better understand what is and is not loaded at any
point in time. If the form that initializes an upload process calls
an ASP file/page that controls the process, and that ASP file/page
includes the actual code in a separate file (yes, I understand about
includes to that point), when the completion of that process calls
another ASP file/page, I presume that the previous file/page/include
is completely unloaded. Yet, the "application" -- "Members.asp" -- is
still the only thing indicated in the address bar, and looking at
"properties" at any stage does not indicate anything more than that
(which is why I was curious about the ability of bots to get beyond
that without reading the ASP code).

You are still not grasping what an application is.

It is the complete us of a website [well sort of]
by all the active users together, which could be thousands.

Any application-object-value is shared by all these users
and could be accessed by asp on each page any user requests.

The application and the aplication-object does not belong to a
file/page, so "Members.asp" is NOT an application.
Even though "Members.asp" meets all of the above criteria? In other words,
"membrs.asp" is the "complete us(e) of a website... by all the active..."
MEMBER "users together". That differentiates the use of the site from
administrative and non-member users, other "applications" that meet those
same criteria. What am I not grasping?

Neil
Aug 6 '08 #30
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Anthony Jones wrote:

Page: "The resultant rendering of HTML" thats the best I can do.

That seems to be a definition from a user's POV. And even then, it's a
little dodgy. Does the fact that different text is displayed in a
browser window make it a different page? Even when the url used to
request it is the same? Yeah, I guess from a user's POV the answer could
be "yes".

From this developer's POV, the page is the file used to generate the
html.

Pages don't generate. Generation implies a machine of some sort. A page
is simply content presented on some form of media. Its the result of a
machine.

In this case it's a script the generates the page and you're right the users
perception is that the content is the page. If the developer drops this
strange notion that a page generates something and realises that a) its the
script which generates and b) ASP is a misnomer and the term 'page' therein
should simply be ignored (or substituted with 'script') then everything
hangs together fine.
--
Anthony Jones - MVP ASP/ASP.NET
Aug 6 '08 #31
Anthony Jones wrote:
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
>Anthony Jones wrote:
>>>
Page: "The resultant rendering of HTML" thats the best I can do.

That seems to be a definition from a user's POV. And even then, it's
a little dodgy. Does the fact that different text is displayed in a
browser window make it a different page? Even when the url used to
request it is the same? Yeah, I guess from a user's POV the answer
could be "yes".

From this developer's POV, the page is the file used to generate the
html.


Pages don't generate. Generation implies a machine of some sort. A
page is simply content presented on some form of media. Its the
result of a machine.

In this case it's a script the generates the page and you're right
the users perception is that the content is the page. If the
OK, let me rephrase that:
" From this developer's POV, the page is the file containing the script
used to generate the html."
developer drops this strange notion that a page generates something
and realises that a) its the script which generates and b) ASP is a
misnomer and the term 'page' therein should simply be ignored (or
substituted with 'script') then everything hangs together fine.
.... except the documentation, which talks about "page scope", the
source of Neil's confusion.
But, yeah, I hear ya: the documentation should instead be talking about
"script scope"

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Aug 6 '08 #32
Bob Barrows [MVP] wrote:
Anthony Jones wrote:
>"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
>>Anthony Jones wrote:

Page: "The resultant rendering of HTML" thats the best I can do.
That seems to be a definition from a user's POV. And even then, it's
a little dodgy. Does the fact that different text is displayed in a
browser window make it a different page? Even when the url used to
request it is the same? Yeah, I guess from a user's POV the answer
could be "yes".

From this developer's POV, the page is the file used to generate the
html.


Pages don't generate. Generation implies a machine of some sort. A
page is simply content presented on some form of media. Its the
result of a machine.

In this case it's a script the generates the page and you're right
the users perception is that the content is the page. If the

OK, let me rephrase that:
" From this developer's POV, the page is the file containing the
script used to generate the html."
>developer drops this strange notion that a page generates something
and realises that a) its the script which generates and b) ASP is a
misnomer and the term 'page' therein should simply be ignored (or
substituted with 'script') then everything hangs together fine.

... except the documentation, which talks about "page scope", the
source of Neil's confusion.
But, yeah, I hear ya: the documentation should instead be talking
about "script scope"
In my use of ASP, the HTML page is generated by populating ASP session
variables within a VB/JScript Function that contains the "wraparound" HTML
code. That file often has many Functions that generate different HTML page
layouts. I have a hard time wrapping my head around the idea that the files
that populate the ASP session variables are also "pages", as they typically
have no HTML content at all. They just do things behind the scene.

But, useful things happen in the process of rendering an HTML page in this
manner. For example, once the HTML is rendered, a script is often completed
(an exception, if the HTML is a Form in the middle of a script), regardless
of whether the ASP file containing that and other scripts is still active.
But, in that context, I may not be conceptualizing "script scope" aka "page
scope" correctly, either.

In the example that I've been using, "members.asp" is active until the user
logs out, but dozens of ASP scripts can execute during that session, even if
only a few HTML pages are rendered. It's confusing and not very useful to
think that there is only one "page" called "members.asp", though that seems
to be the way that some are using the term. I could see "members.asp" as a
"meta-script", and have instead called it an "application", as that is what
it would be in other programming contexts.
;-)

--
Neil
Aug 7 '08 #33

"Neil Gould" <ne**@myplaceofwork.comwrote in message
news:e8***************@TK2MSFTNGP06.phx.gbl...
Bob Barrows [MVP] wrote:
Anthony Jones wrote:
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcomwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Anthony Jones wrote:

Page: "The resultant rendering of HTML" thats the best I can do.
That seems to be a definition from a user's POV. And even then, it's
a little dodgy. Does the fact that different text is displayed in a
browser window make it a different page? Even when the url used to
request it is the same? Yeah, I guess from a user's POV the answer
could be "yes".

From this developer's POV, the page is the file used to generate the
html.

Pages don't generate. Generation implies a machine of some sort. A
page is simply content presented on some form of media. Its the
result of a machine.

In this case it's a script the generates the page and you're right
the users perception is that the content is the page. If the
OK, let me rephrase that:
" From this developer's POV, the page is the file containing the
script used to generate the html."
developer drops this strange notion that a page generates something
and realises that a) its the script which generates and b) ASP is a
misnomer and the term 'page' therein should simply be ignored (or
substituted with 'script') then everything hangs together fine.
... except the documentation, which talks about "page scope", the
source of Neil's confusion.
But, yeah, I hear ya: the documentation should instead be talking
about "script scope"
In my use of ASP, the HTML page is generated by populating ASP session
variables within a VB/JScript Function that contains the "wraparound" HTML
code. That file often has many Functions that generate different HTML page
layouts. I have a hard time wrapping my head around the idea that the
files
that populate the ASP session variables are also "pages", as they
typically
have no HTML content at all. They just do things behind the scene.

But, useful things happen in the process of rendering an HTML page in this
manner. For example, once the HTML is rendered, a script is often
completed
(an exception, if the HTML is a Form in the middle of a script),
regardless
of whether the ASP file containing that and other scripts is still active.
But, in that context, I may not be conceptualizing "script scope" aka
"page
scope" correctly, either.

In the example that I've been using, "members.asp" is active until the
user
logs out, but dozens of ASP scripts can execute during that session, even
if
only a few HTML pages are rendered. It's confusing and not very useful to
think that there is only one "page" called "members.asp", though that
seems
to be the way that some are using the term. I could see "members.asp" as a
"meta-script", and have instead called it an "application", as that is
what
it would be in other programming contexts.
;-)
What do you by ' "members.asp" is active" ??

Once a request is complete the script context is reset. Apart from the
values stored in the application and session objects there is no script that
remains 'active'.

Are you saying that multiple requests from the same client to members.asp
can result in various different responses? Would this variation be a result
of FORM posts or various values on the querystring?
--
Anthony Jones - MVP ASP/ASP.NET
Aug 7 '08 #34

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

52 posts views Thread by Gerard M Foley | last post: by
1 post views Thread by Efkas | last post: by
3 posts views Thread by Steve Koon | last post: by
4 posts views Thread by jcrouse | last post: by
13 posts views Thread by souissipro | last post: by
1 post views Thread by comp.lang.php | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
1 post views Thread by Geralt96 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.