httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: Apache problem (fwd)
Date Tue, 14 May 1996 10:51:46 GMT
> > However, Apache is right to send back the 403, and the browsers would
> > appear to be broken if they don't recognise it properly. Without the
> > ErrorDocument directive, a 403 response would have been sent back anyway...
> > but maybe with a different status string which the broken browsers are
> > incapable of dealing with.
> That doesn't make sense. The clients aren't required to do anything
> with the status string

true, but since when have clients been fool-proof?    :-)

> their behaviour for a 403 response seems
> reasonable to me (except Netscape as it happens since it seems to
> ignore it).

Last time I checked, the HTTP spec said that clients can choose
to do what they want in response to these kinds of headers. Apache
is sending the header (as it should) in order to give the client
the correct info. In addition, it lets the server operator send some
friendly message to explain the problem or to give instructions on
how to fix it or whatever. If a browser chooses to ignore that info,
then it's the programmers decission. When the OmniWeb broswer people
were shown that they were ignoring valuable ErrorDocument info they
soon changed their code to display it...

Educate the browser developers!

> The problem though is that the browser's are hard coded to do certain
> things when they get a 403 response e.g. explorer pops up a window and
> apparently ignores the page.

Then that's a shortcoming of the browser. It's not our job to send
incorrect (200 instead of 403) responses just to keep stooopid browsers
happy. The ErrorDocuemnt creator can send a 200 if (s)he wishes, but
it's not Apache's job to break the rules.

> The whole point of using ErrorDocument in this circumstance is to
> provide an alternative behaviour that's determined by the web author.

the author on the server side has complete control over server output,
but no control over client reaction to it.

> I'm not convinced either way, I'm not clear on whether anything governs
> what browsers are expected to do in these situations.

They do what they please... those that ignore the info need to be
shown what they're missing.

> I'm not sure I'm
> clear on what ErrorDocument is meant to achieve in terms of the spec.

Provide an alternative response.

> Is it just a method of providing an user-defined entity that
> accompanies the standard response code or is it a more powerful
> configuration tool that allows the web author to trap certain codes and
> map them to others so the user does not see errors such as missing
> pages or gets a "normal" response to a mistyped URL that hits your
> site.

It's everything you want it to be, with the defaults being to send
the right headers.


View raw message