render an image from another server

[rich]

We have a web app on an IIS(6) web server.
We store some images on another server (for documents and images)
which is on the same network as the web server.
There is NO domain for this network.

We’ve already lost a couple of hours trying to get the images from the
one server to render in our web app and just can’t do it.
So, in our ASP app, we are referencing the image in this way:

<img src="file://///192.168.1.110/documents/abc.jpg">

I don’t really want to install IIS on the document server do i?

I have tried setting up the same “internet” user from the web server
on the document server, but it prefixes the username with the server
name and doesn't seem to work.

I've tried different ways to reference the file location (file://, \
\servername\image.jpg, etc.)
I've setup mapped network drives
I've set permissions to "everyone", "full control"
Nothing works.

Any ideas?

 

[Michael Fesser]

..oO(rich)

We have a web app on an IIS(6) web server.
We store some images on another server (for documents and images)
which is on the same network as the web server.
There is NO domain for this network.

We’ve already lost a couple of hours trying to get the images from the
one server to render in our web app and just can’t do it.
So, in our ASP app, we are referencing the image in this way:

<img src="file://///192.168.1.110/documents/abc.jpg">

Try file://192.168.1.110/documents/abc.jpg

Micha

 

[Andy Dingley]

We have a web app on an IIS(6) web server.

Irrelevant. This is just a matter for the client web browser and the
media server. The web server sends a HTML page to the browser, which
contains URLs in the <img src="..." > attribute. Then the _browser_
requests this from the media server, without involving the web server
any more.

Do you have a URL to an image that works? e.g.
file://192.168.1.110/documents/abc.jpg
or
http://192.168.1.110/documents/abc.jpg

If you do, then paste that into the HTML on the web server - that's
all you need.

It's not _quite_ all. Stick with "simple" characters and you'll be OK,
but if you have embedded spaces or punctuation in a filename or URL,
you'll have to "percent encode" this when you turn it into a href or
src attribute for the HTML. "foo bar" becomes "foo%20bar"

If you can't get either of these URLs to work FROM THE BROWSER, then
you have a problem. Even if you can access these from the web server,
they need to be accessible from the browser as well.

If you have a file server that's not accessible from the browser, then
you could also configure the web server so that it serves web content
for some virtual directory as coming off that file server. In that
case the HTTP aspect doesn't see the difference at all and just sees
"a big web server" through URLs like this:
<img src="/media/abc.jpg" >

 

[Jukka K. Korpela]

Do you have a URL to an image that works? e.g.
file://192.168.1.110/documents/abc.jpg
or
http://192.168.1.110/documents/abc.jpg

The former cannot work, in WWW terms. Any file: URL indicates a resource to
be accessed in a machine-dependent manner, by definition, so it by
definition won't work on the World Wide Web. It may work inside a computer
or inside a local network. More info:
http://www.cs.tut.fi/~jkorpela/ftpurl.html

The latter postulates that the image is on an HTTP server, which is fine but
something that the OP explicitly wanted to avoid.

If you can't get either of these URLs to work FROM THE BROWSER, then
you have a problem.

Even if you can make them work on a browser, you have a problem at least
with the first one, the ftp: URL, since it won't work on other people's
browsers, except perhaps very locally.

If you have a file server that's not accessible from the browser, then
you could also configure the web server so that it serves web content
for some virtual directory as coming off that file server. In that
case the HTTP aspect doesn't see the difference at all and just sees
"a big web server" through URLs like this:
<img src="/media/abc.jpg" >

I don't quite see the point here, especially since it postulates that the
image is on the same server as the referring HTML document - something that
was specified as not being the case (see the Subject line).

But a different idea popped into my mind: if running an HTTP server is too
much work (and it really requires some time and care), maybe an FTP server
is more feasible. Then you could use ftp: URLs. Not very modern, but
possible.

 

[Adrienne Boswell]

Gazing into my crystal ball I observed rich <[email protected]>
writing in @t13g2000yqc.googlegroups.com:

We have a web app on an IIS(6) web server.
We store some images on another server (for documents and images)
which is on the same network as the web server.
There is NO domain for this network.

We've already lost a couple of hours trying to get the images from the
one server to render in our web app and just can't do it.

If this is a classic ASP page, you might want to post to
microsoft.public.iis.asp.general, otherwise, try one of the dot net groups,
IIRC they have framework in their name.

 

[Harlan Messinger]

.oO(rich)


Try file://192.168.1.110/documents/abc.jpg

Micha

That will be useless for any web client who isn't on the local network
with file system permissions to view that file.

 

[Andy Dingley]

The former cannot work, in WWW terms.

Although the OP didn't state this, I was assuming (from the IP range)
that they're talking about a purely intranet app.

 

[Andy Dingley]

Regarding the file: version: Hardly, unless all intended users are
inside the network (since that's a non-routable IP address) and all have
file system permission to view that file.

That's a common (intranet) situation though. Rather than building a
corporate document store where the web server understands user access
rights, just reference them from the file server with file:// URLs and
let the fileserver decide what they're allowed to see.

 

[Jukka K. Korpela]

Although the OP didn't state this, I was assuming (from the IP range)
that they're talking about a purely intranet app.

They might mean that, but they _said_ "web", which is short for "World Wide
Web".

 

[John Hosking]

They might mean that, but they _said_ "web", which is short for "World
Wide Web".

May I wax pedantic for a moment?

In Microsoftese, "web" doesn't necessarily mean the WWW, no matter
whether any of us think that it should. In FrontPage, the user is
encouraged/instructed/allowed to "create a new web site", or even (in
older versions, say FP98) to "create a new web", in both cases meaning
to produce a site for internal or WWW use. Usually but not always
Microsoft uses a lower-case "w" to refer to these sites, independent of
whether they're published on the WWW.

I claim the above based on my experiences up through FP2002. I don't
know what what used in later versions of FrontPage or any of Microsoft
Expression Web.

In IIS, the entities are referred to "Web Sites" (thusly capitalized),
whether of not they are accessed only locally or via an Internet
connection to the World Wide Web.

Of course, in the case of this thread I think it's hard to make too many
assumptions based on the terminology used. The OP posted to alt.html
(rather than, say, c.i.w.a.h), used GG, hasn't been back yet AFAWK, and
said, "there is NO domain for this network." I'm leaning towards some
internal usage rather than a publicly accessible WWW site, but who knows
for sure?

 

[Guest]

May I wax pedantic for a moment?

Not if you're going to cite "Microsoftese".

<- snip ->