Relative and Absolute Address

[Nick K.]

I recently began maintenance work on a production web server that is located
in the root directory of a web server. I moved this into a sub web on my
local web server in order to do work on it. I found that there is an include
file that references images:

<img src = "/images/Header.gif"

What worked correctly on the production server breaks on mine because of the
absolute address "/images". I removed the absolute address and changed that
to relative "images". This works in some cases but not in all because some
of the asp pages are in sub folders and all include the same include file.

I believe there is addressing like "~/" in .Net that would look in the web
application directory but this doesn't seem to work in asp. Does anyone have
a way to address a gif file from the web application level and not the web
server level?

 

[Chris Barber]

This has been (and still is) the most stupid behaviour ever introduced into IIS and it's been the
bane of my life for some time now. I usually resort to a number of mechanisms to find the correct
reference to the root of the web application (as opposed to site) and *never* use root relative
url - not least of all because it breaks the capability to do local server-side debugging.

You'll have to dig in and replace all those references with either relative references or some
variable reference that replaces the first '/' with the *real* url required.

AFAIK there isn't a simplistic replacement to the root '/' identifier in a url.

Chris


I recently began maintenance work on a production web server that is located
in the root directory of a web server. I moved this into a sub web on my
local web server in order to do work on it. I found that there is an include
file that references images:

<img src = "/images/Header.gif"

What worked correctly on the production server breaks on mine because of the
absolute address "/images". I removed the absolute address and changed that
to relative "images". This works in some cases but not in all because some
of the asp pages are in sub folders and all include the same include file.

I believe there is addressing like "~/" in .Net that would look in the web
application directory but this doesn't seem to work in asp. Does anyone have
a way to address a gif file from the web application level and not the web
server level?

 

[Jeff Dillon]

When you say "sub web", do you mean a virtual directory? This should work as
expected if you mark it as such

Jeff

 

[Roland Hall]

in message
: This has been (and still is) the most stupid behaviour ever introduced
into IIS and it's been the
: bane of my life for some time now. I usually resort to a number of
mechanisms to find the correct
: reference to the root of the web application (as opposed to site) and
*never* use root relative
: url - not least of all because it breaks the capability to do local
server-side debugging.
:
: You'll have to dig in and replace all those references with either
relative references or some
: variable reference that replaces the first '/' with the *real* url
required.
:
: AFAIK there isn't a simplistic replacement to the root '/' identifier in a
url.

So, you're saying "images/someimage.gif" tells you what level "images" is
located at and "/images/someimage.gif" is too difficult to work with?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Roland Hall]

in message : I recently began maintenance work on a production web server that is
located
: in the root directory of a web server. I moved this into a sub web on my
: local web server in order to do work on it. I found that there is an
include
: file that references images:
:
: <img src = "/images/Header.gif"
:
: What worked correctly on the production server breaks on mine because of
the
: absolute address "/images". I removed the absolute address and changed
that
: to relative "images". This works in some cases but not in all because some
: of the asp pages are in sub folders and all include the same include file.
:
: I believe there is addressing like "~/" in .Net that would look in the web
: application directory but this doesn't seem to work in asp. Does anyone
have
: a way to address a gif file from the web application level and not the web
: server level?

Is this ASP or HTML?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Captain Flack]

I recently began maintenance work on a production web server that is located
in the root directory of a web server. I moved this into a sub web on my
local web server in order to do work on it. I found that there is an include
file that references images:

<img src = "/images/Header.gif"

What worked correctly on the production server breaks on mine because of the
absolute address "/images". I removed the absolute address and changed that
to relative "images". This works in some cases but not in all because some
of the asp pages are in sub folders and all include the same include file.

I believe there is addressing like "~/" in .Net that would look in the web
application directory but this doesn't seem to work in asp. Does anyone have
a way to address a gif file from the web application level and not the web
server level?

This isn't an ASP problem as such, it is an HTML one.

Using relative URLs will solve this, e.g.

If the script is in a folder on the root of the web called ASP, and the
images folder is level with it, use:

<img src = "../images/Header.gif"

If the script is on the root and image in the images folder, use

<img src = "images/Header.gif"

etc.

This will work in subfolders because the link is relative to the script
where it appears

 

[Nick K.]

I suppose this is both a ASP and HTML problem. Relative addressing won't
work because of the design of an include file. The include file is included
in ASP pages in both the web application root and folders within the web
application. What I am looking for is relative addressing from the web
application root and not the web site root.

 

[Nick K.]

And what mechanisms might those be?

 

[Roland Hall]

in message : I suppose this is both a ASP and HTML problem. Relative addressing won't
: work because of the design of an include file. The include file is
included
: in ASP pages in both the web application root and folders within the web
: application. What I am looking for is relative addressing from the web
: application root and not the web site root.

Using "images/someimage.gif" you don't know where you are, unless the
application only references folders below the application root level.
Using "../images/someimage.gif" is no different and ridiculous if "images"
is a child to the current directory when "images" will do.
You can also use "./images/someimage.gif" but it is the same as the first
one and a waste of two characters.
If you want to know where the application root is, at all times, then...

dim appPath
appPath = "/my/app/root/is/located/here/"

Now to call for images:

appPath & "images/someimage.gif"

The effective app root would be:
/my/app/root/is/located/here/images/someimage.gif
However, if your folder levels are not that deep, you can eliminate any
processing and just use web root relative paths, which you said you don't
want to do.

I use web root virtual paths directly unless I have folders multiple levels
deep.

"/images/someimage.gif"

dim imgPath
imgPath = "/dev/appName/images/"

You can now just prepend imgPath with the image name.
The biggest benefit to the second is changing path info from development to
production. All I need to modify is imgPath value, which is located in a
common file that is included in other pages. This also works well for
themes, skins, etc.

HTH...

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Phillip Windell]

Is this ASP or HTML?

Rolland !? You're in here too. I think we both must have too much time on
our hands to hang out in all these places

I mostly just read messages in this group and the "*.asp.db" group but don't
post much to keep the foot-in-mouth thing to a minimum.

Nick mentioned "sub-webs" and I think that is key since IIS has no such
thing. I believe that was a FrontPage concept, while IIS only has Sites and
Virtual Folders. I think Jeff Dillon hit on it by suggesting that this
"web" isn't in it's own unique Virtual Folder which causes the Application
Root to be in the wrong place. I'd probably have to play around with it here
for a bit to verify that.

 

[Jeff Dillon]

Just make it a virtual directory, as I suggested.

Jef

 

[Roland Hall]

: : > Is this ASP or HTML?
:
: Rolland !? You're in here too. I think we both must have too much time on
: our hands to hang out in all these places

I try not to hang out in public. (O;= I currently have one network install
and config that is taking forever for them to get the products in, WITH
licensing CALs, NAV Corp. The router was done last week! So, some time
coming from there. Running small calls in between, one development project
in 2nd phase and two others past 1/2 way mark. Waiting to hear on two
additional projects, one could be extensive so you're right, I've got
t-t-t-t-too much time on my hands.

: I mostly just read messages in this group and the "*.asp.db" group but
don't
: post much to keep the foot-in-mouth thing to a minimum.

No foot, no glory.

: Nick mentioned "sub-webs" and I think that is key since IIS has no such
: thing. I believe that was a FrontPage concept, while IIS only has Sites
and
: Virtual Folders. I think Jeff Dillon hit on it by suggesting that this
: "web" isn't in it's own unique Virtual Folder which causes the Application
: Root to be in the wrong place. I'd probably have to play around with it
here
: for a bit to verify that.

HOW TO: Create a Virtual Folder (Subweb) in IIS 4.0 or IIS 5.0
http://support.microsoft.com/default.aspx?scid=kb;en-us;301392&sd=tech

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp

 

[Chris Barber]

A root relative path e.g.:

'/images'

when called from a virtual directory still references from the root of the *website*, not the root
of the virtual directory (as might be expected).

It's a RRPITA (Right Royal Pain In The ...) and breaks almost all aspects of doing 'local-mode' ASP
debugging (where a website will be moved to a virtual directory on the local IIS).

My advice ... don't *ever* use them, user relative paths or a script to determine the root of the
'site' (e.g. your virtual directory) and path references from that.

Chris.

Just make it a virtual directory, as I suggested.

Jef

 

[Alan Howard]

Not to mention that Server.MapPath seems to map to the root of the site,
which could be in a completely different location, then simply appends the
'tree' from your virtual directory down. Like you say - a real pain.

A root relative path e.g.:

'/images'

when called from a virtual directory still references from the root of the *website*, not the root
of the virtual directory (as might be expected).

It's a RRPITA (Right Royal Pain In The ...) and breaks almost all aspects of doing 'local-mode' ASP
debugging (where a website will be moved to a virtual directory on the local IIS).

My advice ... don't *ever* use them, user relative paths or a script to determine the root of the
'site' (e.g. your virtual directory) and path references from that.

Chris.

Just make it a virtual directory, as I suggested.

Jef

 

[Mark Schupp]

Not to mention that Server.MapPath seems to map to the root of the site,

which could be in a completely different location, then simply appends the
'tree' from your virtual directory down. Like you say - a real pain.

I've heard this comment before but I have never been able to duplicate it.
For example:

localhost => c:\inetpub\wwwroot
localhost/wbtmanager => c:\wbtman\web

The following code:

response.write server.MapPath("/wbtmanager/test.asp") & "<br>"
response.write server.MapPath("./test.asp") & "<br>"

displays:

C:\wbtman\web\test.asp
C:\wbtman\web\test.asp

Which is what I would expect.

Maybe I'm missing something. Can you give an example of where MapPath
prepends the path to the site rather than the path to the virtual directory?

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com

Not to mention that Server.MapPath seems to map to the root of the site,
which could be in a completely different location, then simply appends the
'tree' from your virtual directory down. Like you say - a real pain.

A root relative path e.g.:

'/images'

when called from a virtual directory still references from the root of

the
*website*, not the root

of the virtual directory (as might be expected).

It's a RRPITA (Right Royal Pain In The ...) and breaks almost all

aspects
of doing 'local-mode' ASP

 

[Jeff Dillon]

You appear to be correct..just tried it.

A root relative path e.g.:

'/images'

when called from a virtual directory still references from the root of the *website*, not the root
of the virtual directory (as might be expected).

It's a RRPITA (Right Royal Pain In The ...) and breaks almost all aspects of doing 'local-mode' ASP
debugging (where a website will be moved to a virtual directory on the local IIS).

My advice ... don't *ever* use them, user relative paths or a script to determine the root of the
'site' (e.g. your virtual directory) and path references from that.

Chris.

Just make it a virtual directory, as I suggested.

Jef