transparent redirection in asp

Discussion in 'ASP General' started by rvj, Aug 2, 2008.

  1. rvj

    rvj Guest

    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
    rvj, Aug 2, 2008
    #1
    1. Advertising

  2. rvj

    rvj Guest

    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" <> wrote in message
    news:...
    >
    > 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
    >
    rvj, Aug 2, 2008
    #2
    1. Advertising

  3. Gazing into my crystal ball I observed "rvj" <>
    writing in news::

    >
    > 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
    Adrienne Boswell, Aug 2, 2008
    #3
  4. "rvj" <> wrote in message
    news:...
    > 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
    Anthony Jones, Aug 2, 2008
    #4
  5. rvj

    rvj Guest


    > 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/library/ms972974(printer).aspx

    "Adrienne Boswell" <> wrote in message
    news:Xns9AEE5EBBBE416arbpenyahoocom@69.16.185.247...
    > Gazing into my crystal ball I observed "rvj" <>
    > writing in news::
    >
    >>
    >> 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
    >
    rvj, Aug 3, 2008
    #5
  6. rvj

    rvj Guest

    > 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" <> wrote in message
    news:%...
    > "rvj" <> wrote in message
    > news:...
    >> 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
    >
    >
    rvj, Aug 3, 2008
    #6
  7. "rvj" <> wrote in message
    news:...
    >
    > > 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
    Anthony Jones, Aug 3, 2008
    #7
  8. rvj

    rvj Guest

    > 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" <> wrote in message
    news:...
    > "rvj" <> wrote in message
    > news:...
    >>
    >> > 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
    >
    >
    rvj, Aug 3, 2008
    #8
  9. "rvj" <> wrote in message
    news:...
    > > 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
    Anthony Jones, Aug 3, 2008
    #9
  10. rvj

    Neil Gould Guest

    Hi Adrienne,

    Adrienne Boswell wrote:
    > Gazing into my crystal ball I observed "rvj" <>
    > writing in news::
    >
    >>
    >> 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
    Neil Gould, Aug 4, 2008
    #10
  11. Gazing into my crystal ball I observed "Neil Gould"
    <> writing in news:OCkPeDi9IHA.2336
    @TK2MSFTNGP03.phx.gbl:

    > Hi Adrienne,
    >
    > Adrienne Boswell wrote:
    >> Gazing into my crystal ball I observed "rvj" <>
    >> writing in news::
    >>
    >>>
    >>> 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
    Adrienne Boswell, Aug 4, 2008
    #11
  12. "Adrienne Boswell" <> wrote in message
    news:Xns9AF047F0DB2A5arbpenyahoocom@69.16.185.250...
    > Gazing into my crystal ball I observed "Neil Gould"
    > <> writing in news:OCkPeDi9IHA.2336
    > @TK2MSFTNGP03.phx.gbl:
    >
    >> Hi Adrienne,
    >>
    >> Adrienne Boswell wrote:
    >>> Gazing into my crystal ball I observed "rvj" <>
    >>> writing in news::
    >>>
    >>>>
    >>>> 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
    Mike Brind [MVP], Aug 5, 2008
    #12
  13. rvj

    Evertjan. Guest

    Mike Brind [MVP] wrote on 05 aug 2008 in
    microsoft.public.inetserver.asp.general:
    >
    > "Adrienne Boswell" <> wrote 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)
    Evertjan., Aug 5, 2008
    #13
  14. rvj

    Neil Gould Guest

    Evertjan. wrote:
    > Mike Brind [MVP] wrote on 05 aug 2008 in
    > microsoft.public.inetserver.asp.general:
    >>
    >> "Adrienne Boswell" <> wrote 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
    Neil Gould, Aug 5, 2008
    #14
  15. rvj

    Evertjan. Guest

    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" <> wrote 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)
    Evertjan., Aug 5, 2008
    #15
  16. rvj

    Evertjan. Guest

    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)
    Evertjan., Aug 5, 2008
    #16
  17. rvj

    Evertjan. Guest

    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)
    Evertjan., Aug 5, 2008
    #17
  18. rvj

    Neil Gould Guest

    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
    Neil Gould, Aug 5, 2008
    #18
  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.
    Bob Barrows [MVP], Aug 5, 2008
    #19
  20. rvj

    Evertjan. Guest

    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)
    Evertjan., Aug 5, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan Moore

    ASP.NET Page "Redirection"

    Ryan Moore, Oct 1, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    493
    Ryan Moore
    Oct 1, 2004
  2. Subrata
    Replies:
    1
    Views:
    631
    Hans Kesting
    May 4, 2006
  3. jobs
    Replies:
    0
    Views:
    3,869
  4. Replies:
    2
    Views:
    150
  5. Replies:
    3
    Views:
    163
    B Wisentaner
    Dec 11, 2005
Loading...

Share This Page