transparent redirection in asp

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" <rvj@rolemodels.netwrote in message
news:uFETNtK9IHA.356@TK2MSFTNGP02.phx.gbl...

Quote: Originally Posted by > 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 >

Gazing into my crystal ball I observed "rvj" <rvj@rolemodels.net>
writing in news:uFETNtK9IHA.356@TK2MSFTNGP02.phx.gbl:

Quote: Originally Posted by > 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?

Quote: Originally Posted by > 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.

Quote: Originally Posted by > 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

"rvj" <rvj@rolemodels.netwrote in message
news:O3zkYjL9IHA.3612@TK2MSFTNGP04.phx.gbl...

Quote: Originally Posted by 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

Quote: Originally Posted by 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

Quote: Originally Posted by 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

Quote: Originally Posted by 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

Quote: Originally Posted by 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/lib...4(printer).aspx

"Adrienne Boswell" <arbpen@yahoo.comwrote in message
news:Xns9AEE5EBBBE416arbpenyahoocom@69.16.185.247. ..

Quote: Originally Posted by Gazing into my crystal ball I observed "rvj" <rvj@rolemodels.net> writing in news:uFETNtK9IHA.356@TK2MSFTNGP02.phx.gbl: > Quote: Originally Posted by >> >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? > Quote: Originally Posted by >> >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. > Quote: Originally Posted by >> >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 >

Your server could make the request to the other server on behalf ot the

Quote: Originally Posted by client and return the response.

that was solution I was suggesting >" making serverside http requests and
using
response.write to display it"

Quote: Originally Posted by However as was asked by Adrienne, why would you need this?

URL to URI migration



"Anthony Jones" <Ant@yadayadayada.comwrote in message
news:%23aYhEsM9IHA.6084@TK2MSFTNGP05.phx.gbl...

Quote: Originally Posted by "rvj" <rvj@rolemodels.netwrote in message news:O3zkYjL9IHA.3612@TK2MSFTNGP04.phx.gbl... Quote: Originally Posted by >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 Quote: Originally Posted by >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 > >

"rvj" <rvj@rolemodels.netwrote in message
news:uEOQyAT9IHA.4588@TK2MSFTNGP02.phx.gbl...

Quote: Originally Posted by > Quote: Originally Posted by 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

Quote: Originally Posted by 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.

Quote: Originally Posted by Quote: Originally Posted by 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

Quote: Originally Posted by 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

Quote: Originally Posted by 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

However it still isn't clear why the URL in the browser must not change.

Quote: Originally Posted by 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" <Ant@yadayadayada.comwrote in message
news:uBPGz3T9IHA.5700@TK2MSFTNGP02.phx.gbl...

Quote: Originally Posted by "rvj" <rvj@rolemodels.netwrote in message news:uEOQyAT9IHA.4588@TK2MSFTNGP02.phx.gbl... Quote: Originally Posted by >> Quote: Originally Posted by 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 Quote: Originally Posted by >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. > Quote: Originally Posted by Quote: Originally Posted by 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 Quote: Originally Posted by >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 Quote: Originally Posted by >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 > >

"rvj" <rvj@rolemodels.netwrote in message
news:O9d3wtY9IHA.5928@TK2MSFTNGP05.phx.gbl...

Quote: Originally Posted by Quote: Originally Posted by 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

Hi Adrienne,

Adrienne Boswell wrote:

Quote: Originally Posted by Gazing into my crystal ball I observed "rvj" <rvj@rolemodels.net> writing in news:uFETNtK9IHA.356@TK2MSFTNGP02.phx.gbl: > Quote: Originally Posted by >> >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

Gazing into my crystal ball I observed "Neil Gould"
<neil@myplaceofwork.comwriting in news:OCkPeDi9IHA.2336
@TK2MSFTNGP03.phx.gbl:

Quote: Originally Posted by Hi Adrienne, > Adrienne Boswell wrote: Quote: Originally Posted by >Gazing into my crystal ball I observed "rvj" <rvj@rolemodels.net> >writing in news:uFETNtK9IHA.356@TK2MSFTNGP02.phx.gbl: >> Quote: Originally Posted by >>> >>if you redirect on an IIS , must the client url address bar always

be

Quote: Originally Posted by Quote: Originally Posted by Quote: Originally Posted by >>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

Quote: Originally Posted by rather old and I understand why it was iffy to use frames about a

decade

Quote: Originally Posted by ago. Is there any current reason why you feel that using frames is a

bad

Quote: Originally Posted by 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

"Adrienne Boswell" <arbpen@yahoo.comwrote in message
news:Xns9AF047F0DB2A5arbpenyahoocom@69.16.185.250. ..

Quote: Originally Posted by Gazing into my crystal ball I observed "Neil Gould" <neil@myplaceofwork.comwriting in news:OCkPeDi9IHA.2336 @TK2MSFTNGP03.phx.gbl: > Quote: Originally Posted by >Hi Adrienne, >> >Adrienne Boswell wrote: Quote: Originally Posted by >>Gazing into my crystal ball I observed "rvj" <rvj@rolemodels.net> >>writing in news:uFETNtK9IHA.356@TK2MSFTNGP02.phx.gbl: >>> >>>> >>>if you redirect on an IIS , must the client url address bar always be Quote: Originally Posted by Quote: Originally Posted by >>>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 Quote: Originally Posted by >rather old and I understand why it was iffy to use frames about a decade Quote: Originally Posted by >ago. Is there any current reason why you feel that using frames is a bad Quote: Originally Posted by >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

Mike Brind [MVP] wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:

Quote: Originally Posted by > "Adrienne Boswell" <arbpen@yahoo.comwrote in message Quote: Originally Posted by >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)

Evertjan. wrote:

Quote: Originally Posted by Mike Brind [MVP] wrote on 05 aug 2008 in microsoft.public.inetserver.asp.general: Quote: Originally Posted by >> >"Adrienne Boswell" <arbpen@yahoo.comwrote in message Quote: Originally Posted by >>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?

Quote: Originally Posted by 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.

Quote: Originally Posted by 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

Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:

Quote: Originally Posted by Evertjan. wrote: Quote: Originally Posted by >Mike Brind [MVP] wrote on 05 aug 2008 in >microsoft.public.inetserver.asp.general: Quote: Originally Posted by >>> >>"Adrienne Boswell" <arbpen@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.

Quote: Originally Posted by Quote: Originally Posted by >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.

Quote: Originally Posted by Quote: Originally Posted by >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.

Quote: Originally Posted by 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.

Quote: Originally Posted by 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.

Quote: Originally Posted by which is why I asked.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

Evertjan. wrote:

Quote: Originally Posted by Neil Gould wrote on 05 aug 2008 in microsoft.public.inetserver.asp.general: > Quote: Originally Posted by Quote: Originally Posted by >>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.

Quote: Originally Posted by Quote: Originally Posted by >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.

Quote: Originally Posted by Quote: Originally Posted by Quote: Originally Posted by >>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".

Quote: Originally Posted by Only the rendered byte stream, usually html [with clientside scripting and css], is sent to the client. >

Of course.

Quote: Originally Posted by Quote: Originally Posted by >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.

Quote: Originally Posted by Quote: Originally Posted by >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. ;-)

Quote: Originally Posted by 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

Neil Gould wrote on 05 aug 2008 in
microsoft.public.inetserver.asp.general:

Quote: Originally Posted by Quote: Originally Posted by Quote: Originally Posted by >>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.

Quote: Originally Posted by > 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.

Quote: Originally Posted by 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?

Quote: Originally Posted by Quote: Originally Posted by Quote: Originally Posted by >>If there is a "gotcha" in such an approach, I haven't seen it yet,

Quote: Originally Posted by Quote: Originally Posted by >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. ;-) > Quote: Originally Posted by >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.

Quote: Originally Posted by with many other functions containing other HTML pages.

A function does not contain a page.

Quote: Originally Posted by 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.

Quote: Originally Posted by or even the location of that include file,

We were talking cloacking with a frameset with a single frame!

Quote: Originally Posted by 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)

Evertjan. wrote:

Quote: Originally Posted by Neil Gould wrote on 05 aug 2008 in microsoft.public.inetserver.asp.general: > Quote: Originally Posted by Quote: Originally Posted by >>>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.

Quote: Originally Posted by Quote: Originally Posted by >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.

Quote: Originally Posted by Quote: Originally Posted by >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.

Quote: Originally Posted by Quote: Originally Posted by Quote: Originally Posted by >>>If there is a "gotcha" in such an approach, I haven't seen it yet, > Quote: Originally Posted by Quote: Originally Posted by >>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. ;-) >> Quote: Originally Posted by >>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. > Quote: Originally Posted by >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.

Quote: Originally Posted by Quote: Originally Posted by >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?

Quote: Originally Posted by Quote: Originally Posted by >or even the location of that include file, > We were talking cloacking with a frameset with a single frame! > Quote: Originally Posted by >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

Neil Gould wrote on 06 aug 2008 in
microsoft.public.inetserver.asp.general:

Quote: Originally Posted by Evertjan. wrote: Quote: Originally Posted by >Neil Gould wrote on 05 aug 2008 in >microsoft.public.inetserver.asp.general: >> Quote: Originally Posted by >>>>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 "Applicat