Thanks for clarifying that your problem is actually due to a coding error in
your 401 page and has nothing to do with IIS. Please allow me to try and
explain the logic of what is actually going on, show why your comparison
remains apples-to-oranges, and finally give advice on how to fix your coding
error.
Based on your clarification:
Suppose you make a request to
<a style='text-decoration: underline;' href="http://server/needs-authentication-vdir/page.asp" target="_blank">http://server/needs-authentication-vdir/page.asp</a> and the user fails to
authenticate correctly. Since you configured IIS to send a staic for this
custom error, IIS will send the file as-is back to the client (with a proper
401 HTTP header prepended, of course, so that the client can interpret it
correctly).
Now, a 401 response comes back to the client, and the entite body is the
static file you configured, including <img src="401.gif"> . The browser
parses the response and notices <img src="401.gif"> . Since a part of the
Graphical browser's job is to automatically fetch IMG links to compose the
HTML page for display, it is going to make a new request for this resource
prior to displaying 401.htm
What request do you think the browser makes to fetch the 401.gif ???
Based on your thought process, I think that since you "proved" with a local
File browse that the 401.htm can "see" the 401.gif, you think that if you
somehow configure IIS to send the 401.htm to the browser then everything
must automatically work -- the browser must be able to fetch the 401.gif --
it's in the same directory, after all.
Not so fast -- computing is very logical -- and the above thought process
borders on magical intuition. What is happening is this:
We are talking about web browsers and web servers in a client/server
relationship, where browsers only make requests and servers only send
responses to requests. The browser made a request for
<a style='text-decoration: underline;' href="http://server/needs-authentication-vdir/page.asp" target="_blank">http://server/needs-authentication-vdir/page.asp</a> and got back a response (so
it's not going to show a 404 page -- it got a response back). The browser
parses the response and notices <img src="401.gif"> in the response and is
obligated to make another request to retrieve this URL to finish display
composition of 401.htm. Since you gave a relative URL for the IMG SRC and
didn't declare an alternative BASE URL in the HTML page, the browser can
only assume to make a request to
<a style='text-decoration: underline;' href="http://server/needs-authentication-vdir/401.gif" target="_blank">http://server/needs-authentication-vdir/401.gif</a> to retrieve that resource.
It doesn't matter if it isn't what you intend to happen; it's what you
coded. Remember -- there is a client/server relationship and the browser
has no knowledge of file layout on the server; it can only compose names
based on semantic clues in the HTML and make HTTP requests to retrieve those
resources from a remote namespace.
My next question is:
Is the browser's request to <a style='text-decoration: underline;' href="http://server/needs-authentication-vdir/401.gif" target="_blank">http://server/needs-authentication-vdir/401.gif</a>
going to succeed or fail?
My suspicion is that this request will fail -- you just failed to access
page.asp in that virtual directory and told the browser to not
auto-authenticate, so it is going to fail to request 401.gif -- and display
an empty place-holder icon for <img src="401.gif">
I hope you now see how this failure pattern is due to a problem in your HTML
code and is exactly what I pointed out earlier:
--> Did you make *those* URL links of images/CSS accessible to an
unauthenticated user so that the remote browser can retrieve them?
Finally, your comparison "proof" of 401.htm working as a file but not over
HTTP remains apples-to-oranges. The reason your approach is
apples-to-oranges is this:
When you view 401.htm from the local filesystem, the browser's implicit
"base URL" is set to the local directory containing the 401.htm (it's all
part of the IE/Windows Shell integration) -- so <img src="401.gif"> resolves
to be in the same directory as the 401.htm itself. And since your login
identity has access to that directory and those two files, everything looks
good.
This all breaks down when you request it over HTTP as I explained earlier.
The web browser is NOT browsing to 401.htm -- the web browser is retrieving
some other URL and IIS sends the content of 401.htm as a response. Thus,
the base URL that the browser uses to resolve a relative URL like <img
src="401.gif"> is going to be arbitrary and certainly has no relevance to
the physical location of 401.htm.
Now, how should you fix this?
Clearly, you need to do these two things:
1. Make sure 401.gif is accessible in the server's URL Namespace for the
browser to access
2. Author 401.htm such that its URL references to 401.gif unambiguously
resolves to the same namespace as in #1
You can do this in a variety of ways:
- To satisfy requirement #1, you need to expose an anonymous-authenticated
vdir containing 401.gif. This exposes the physical 401.gif file in the URL
namespace added by the vdir, so that a browser can make a request to fetch
401.gif
- To satisfy requirement #2, you need to:
- Author 401.htm using absolute URL names, like /images/401.gif , so that
the browser knows where to fetch 401.gif
- Author 401.htm using relative URL names like 401.gif, but declare a Base
URL directive so that browsers interpret relative URLs correctly to fetch
401.gif
i.e.
Set up a vdir called /images which contains 401.gif
Author 401.htm to contain <IMG SRC="/images/401.gif">
And voila, things should work. I just went and customized my 401.x error
pages in this fashion and it works great.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Mark" <mark-at-redfox-co-uk> wrote in message
news:OkcK2gxoEHA.2032@TK2MSFTNGP10.phx.gbl...
Thanks for your reply, perhaps I should clarify the steps I took.
To try and keep things at their most basic I placed a small gif
C:\WINDOWS\Help\iisHelp\common folder and edited the 401-3.htm file to
display that gif. I choose 401-3 because that is that page that displays if
I press cancel when the authentication dialogue window is cancelled.
The gif is not linked back to a path in the virtual server generating the
401 error, it is in the same folder as the 401-3 file itself and I did this
to avoid exactly the situation you describe. My thought process was that,
whatever happens, the user must have the necessary credentials or the 401-3
page itself would not display. What I get is the 401 page with an empty
placeholder of the graphic, not a 404 page.
I understand that the sucurity context of the locally logged on user is not
the same as anonymous internet access, my point about the gif displaying to
the locally logged on user served only to illustrate that the problem was
not an html coding error.
I dont think the issue is one of security context (just to be sure I have
just tried again granting rwx for IWAM, IUSR and everyone to
C:\WINDOWS\Help\iisHelp\common, which did not help). I wonder if the
problem is more likely to be one of what map path is in use when IIS sends
back a 401 page (the html does not reference a path the tag is <img
src="401.gif">)
Mark
"David Wang [Msft]" <someone.DeleteThis@online.microsoft.com> wrote in message
news:eGz6ZSroEHA.2764@TK2MSFTNGP11.phx.gbl...
> > I realise it has to be a static page, but is there a limitation as
> > to including images or css formatting in the page? It seems to
> > fail to locate any graphic files, and text formatting must be
> > done within the page itself, which seems very basic.
>
> No, custom errors do not have the limitations that you are imagining. I
> think you are just misconfiguring the server and mis-authoring the
401.htm.
>
> You need to realize that 401.x indicates authentication failure of some
> sort, so IIS has no user context with which to execute a request.
>
> So, the 401.htm is a static file that IIS sends back to the browser, but
you
> modified it such that it now contains URL links to images/CSS BACK to the
> web server that the browser just failed authentication. The key question
> now is:
> Did you make *those* URL links of images/CSS accessible to an
> unauthenticated user so that the remote browser can retrieve them?
>
> If you did not, then an unauthenticated user first will get the 401.htm
for
> accessing something that requires authentication, and then also get 404
file
> not found or 401 access denied for each retrieval of the graphics/CSS
files
> referenced by the 401.htm -- thus have missing images/CSS.
>
>
> > If I drop a simple gif file in the iishelp\common folder and
> > edit the 401.htm to include the image, it is missing when
> > viewed over http (but works fine if the file is opened locally).
>
> I don't know if you realize this, but your comparison is actually
> inconclusive and wrong.
>
> Viewing the page over HTTP is not comparable to viewing it as a local
file.
> In the former case, there is a client/server interaction happening, and an
> impersonated identity by the server is actually accessing the
pages/graphics
> as governed through any client/server authentication protocols. In the
> latter, there is no client/server interaction and it is simply your logon
> identity opening files on the local filesystem. Clearly, privileges and
> user identity are different between the two cases, so your comparison is
> apples to oranges.
>
> --
> //David
> IIS
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "Mark" <mark-at-redfox-co-uk> wrote in message
> news:e0mYVgpoEHA.896@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> As per an earlier post, I too, am trying to create custom error pages, but
> finding the 401 page is giving me problems.
>
> I realise it has to be a static page, but is there a limitation as to
> including images or css formatting in the page? It seems to fail to
locate
> any graphic files, and text formatting must be done within the page
itself,
> which seems very basic.
>
> If I drop a simple gif file in the iishelp\common folder and edit the
> 401.htm to include the image, it is missing when viewed over http (but
works
> fine if the file is opened locally).
>
> Is this right?
>
> Mark
>
>
>
>
><!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: Custom 401 page problems