You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Joshua Slive <jo...@slive.ca> on 2001/08/20 21:28:10 UTC

error docs

I still haven't actually tried this stuff on a real server, so take this
with a grain of salt.  But anyway, here are some comments/questions based
on a slightly more careful look:

1. Any objection to combining header.html with top.html and footer.html
with bottom.html?  As long as we are saving filesystem mucking, this seems
like any easy score, and it makes the whole setup more clear from my
perspective.  (Once the includes get a few levels deap, I start to get
dizzy.)

The same goes for including contact.html and spacer.html directly
in header and footer where appropriate.

2. I'm not sure how comfortable I am with this:
<TABLE BORDER=0 CELLPADDING=6 WIDTH="100%">
<TR><TD ALIGN=CENTER BGCOLOR="#000000">
<FONT SIZE="+2" COLOR="#FFFFFF"><strong><!--#echo encoding="none"
var="TITLE" --></strong></FONT>
</TD></TR></TABLE>

I know this technique (white text on a black table cell) is common
and it looks nice.  But I'm afraid that there are browsers out there that
can interpret the <font color=... tag, but can't interpret the <td
bgcolor=... tag.  The result would be white on white.

My preference is just a plain old <h1>...</h1>.  (We could even include a
stylesheet if we want to be fancy.)

3. The contact.html includes should probably be wrapped with an if-test
for INCLUDE_SERVER_ADMIN.  I'm sure there are people who prefer not to put
an email address on all these error pages.

4. I'm not sure that I see the point of the cache-control and pragma
HTTP-Equiv stuff.  Shouldn't we be letting the cache decide for itself
whether to cache based on the status code/etc.  Are the caches out there
so bad that they can't be trusted with this decision?

5. Some of the pages include <!--#echo encoding="none"
var="REDIRECT_METHOD"-->.  Is that safe?  Shouldn't those be
encoded in some way to prevent the client from shoving nasty methods at
us, or is this variable safe?


If I don't get answers or objections to these points, I will make the
changes myself.

Joshua.


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


Re: error docs

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Joshua Slive" <jo...@slive.ca>
Sent: Monday, August 20, 2001 2:28 PM


> I still haven't actually tried this stuff on a real server, so take this
> with a grain of salt.  But anyway, here are some comments/questions based
> on a slightly more careful look:
> 
> 1. Any objection to combining header.html with top.html and footer.html
> with bottom.html?  As long as we are saving filesystem mucking, this seems
> like any easy score, and it makes the whole setup more clear from my
> perspective.  (Once the includes get a few levels deap, I start to get
> dizzy.)
> 
> The same goes for including contact.html and spacer.html directly
> in header and footer where appropriate.

No objection here.  Note that spacer actually appears within the messages.
Wonder if the header could simple set up a 'spacer' variable, so we don't
actually do an include.

For that matter, wonder if the header could simply set up the footer text
for substitution, without reading another file.

But your simple start sounds good.

> 2. I'm not sure how comfortable I am with this:
> <TABLE BORDER=0 CELLPADDING=6 WIDTH="100%">
> <TR><TD ALIGN=CENTER BGCOLOR="#000000">
> <FONT SIZE="+2" COLOR="#FFFFFF"><strong><!--#echo encoding="none"
> var="TITLE" --></strong></FONT>
> </TD></TR></TABLE>
> 
> I know this technique (white text on a black table cell) is common
> and it looks nice.  But I'm afraid that there are browsers out there that
> can interpret the <font color=... tag, but can't interpret the <td
> bgcolor=... tag.  The result would be white on white.
> 
> My preference is just a plain old <h1>...</h1>.  (We could even include a
> stylesheet if we want to be fancy.)

That's what I would prefer, throughout the pages.  If we want to be 'cool',
let's use style sheets exclusively.  Depreicate all <tag bogus=fooness>, and
create a style sheet in htdocs.html.  Have them name=ap-identifier so we
can create a real style base.  And then (if we disagree on the actual style :)
offer more than one 'choice'.  See the w3.org site for a good collection, and
just choose one that we can start with.

Unless it's a manditory style change (such as some autoindex stuff that must
be parsable by html 3.0 generation clients) let's leave asthetics to stylesheet
based browsers.  Text/reader based browsers don't need all this cruft, anyways.

> 3. The contact.html includes should probably be wrapped with an if-test
> for INCLUDE_SERVER_ADMIN.  I'm sure there are people who prefer not to put
> an email address on all these error pages.

That's the definition of the ServerAdmin directive.  If they don't want it, we
drop the admin's name.  You can test that the variable is defined.

> 4. I'm not sure that I see the point of the cache-control and pragma
> HTTP-Equiv stuff.  Shouldn't we be letting the cache decide for itself
> whether to cache based on the status code/etc.  Are the caches out there
> so bad that they can't be trusted with this decision?

We should be letting the server config decide (specifically, the error handler
better deal with these within Apache, it's arguable [moot] in the .html content.

> 5. Some of the pages include <!--#echo encoding="none"
> var="REDIRECT_METHOD"-->.  Is that safe?  Shouldn't those be
> encoded in some way to prevent the client from shoving nasty methods at
> us, or is this variable safe?

Need to contemplate that.  Probably not, but I think -our-modules- mostly
determine the redirect method.  That needs testing.

> If I don't get answers or objections to these points, I will make the
> changes myself.

Attack :)


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


RE: error docs

Posted by Joshua Slive <sl...@commerce.ubc.ca>.
On Tue, 21 Aug 2001, Lars Eilebrecht wrote:

> According to Joshua Slive:
>
> >  I still haven't actually tried this stuff on a real server, so take this
> >  with a grain of salt.
>
> BTW, here are two examples of real servers to play with...
>
> http://www.cablewireless.de/  (based on version 1.2, en, de, fr, us)
> http://www.unix-ag.org/       (based on version 1.1, en, de)

Thanks.  I hope you are going to beat on me too hard for tearing up all
your great work on the SSI stuff.  Feel free to put it back if you think
it should be there.

Anyway, here is an example of the new, simplified stuff from a base
Apache configuration as of 10pm EST:

http://finance.commerce.ubc.ca:8080/

A couple error pages:
http://finance.commerce.ubc.ca:8080/asdfa
http://finance.commerce.ubc.ca:8080/cgi-bin/

Joshua.


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


RE: error docs

Posted by Lars Eilebrecht <la...@hyperreal.org>.
According to Joshua Slive:

>  I still haven't actually tried this stuff on a real server, so take this
>  with a grain of salt. 

BTW, here are two examples of real servers to play with...

http://www.cablewireless.de/  (based on version 1.2, en, de, fr, us)
http://www.unix-ag.org/       (based on version 1.1, en, de)


ciao...
-- 
Lars Eilebrecht                 - I like work; it fascinates me...
lars@hyperreal.org             - I can sit and watch it for hours.


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


Re: error docs

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Lars Eilebrecht" <la...@hyperreal.org>
Sent: Monday, August 20, 2001 6:01 PM



> Are we now keeping the error docs in httpd-2.0 instead of httpd-docs-2.0?
> I just noticed that OtherBill moved some of the files to httpd-2.0.

only our default index.html.foo goes in docroot.  images, manual, and icons
are all seperate entities (along with conf and some others) in httpd-2.0/docs.




---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org


RE: error docs

Posted by Lars Eilebrecht <la...@hyperreal.org>.
According to Joshua Slive:

>  1. Any objection to combining header.html with top.html and footer.html
>  with bottom.html?  As long as we are saving filesystem mucking, this seems
>  like any easy score, and it makes the whole setup more clear from my
>  perspective.

+1

  
>  The same goes for including contact.html and spacer.html directly
>  in header and footer where appropriate.

-1
contact.html cannot be included, because it contains the info text
about the admin or other contact persons and is available in
multiple languages.
spacer.html may be used in the error docs itself and must a
seperate file.

>  2. I'm not sure how comfortable I am with this:
>  <TABLE BORDER=0 CELLPADDING=6 WIDTH="100%">
>  <TR><TD ALIGN=CENTER BGCOLOR="#000000">
>  <FONT SIZE="+2" COLOR="#FFFFFF"><strong><!--#echo encoding="none"
>  var="TITLE" --></strong></FONT>
>  </TD></TR></TABLE>
>  
>  I know this technique (white text on a black table cell) is common
>  and it looks nice.  But I'm afraid that there are browsers out there that
>  can interpret the <font color=... tag, but can't interpret the <td
>  bgcolor=... tag.  The result would be white on white.

Well, I see your point, but the text in the two tables on the top
and bottom on the page don't contain any relevant information. The text
in the table on top contains the document title and the table on bottom
contains the status code (which is more or less useful to most users).
The idea is simple to have 'nicer' error messages compared to the original
ones and give the user some base for designing his own message look.
  
>  My preference is just a plain old <h1>...</h1>.

But that's sooo boring. :-)


>  (We could even include a stylesheet if we want to be fancy.)

Stylesheets would be cool.


>  3. The contact.html includes should probably be wrapped with an if-test
>  for INCLUDE_SERVER_ADMIN.  I'm sure there are people who prefer not to put
>  an email address on all these error pages.

Oh, that was the idea behind this variable. Looks like that the current
version of the docs is missing the check. *shrug*

>  4. I'm not sure that I see the point of the cache-control and pragma
>  HTTP-Equiv stuff.  Shouldn't we be letting the cache decide for itself
>  whether to cache based on the status code/etc.  Are the caches out there
>  so bad that they can't be trusted with this decision?

I've no opinion on keeping or deleting these meta entries. They are just
there to be super safe if a robot/client end up on the error page and
would have stored/cached the page. Please consider that it is possible
to directly access a document in the error directory. In this case
status is 200 and the page might be stored in the robot's database or
cached by a proxy cache.

>  5. Some of the pages include <!--#echo encoding="none"
>  var="REDIRECT_METHOD"-->.  Is that safe?  Shouldn't those be
>  encoded in some way to prevent the client from shoving nasty methods at
>  us, or is this variable safe?

IMHO it's safe. There was a reason why I used no encoding, but I
don't recall it at the moment.
Hmm... I just tested this (1.3.21-dev) by doing a simple POST request
to a static HTML file, but REDIRECT_METHOD was actually undefined.
*ouch* This should be REDIRECT_REQUEST_METHOD instead.


Are we now keeping the error docs in httpd-2.0 instead of httpd-docs-2.0?
I just noticed that OtherBill moved some of the files to httpd-2.0.

ciao...
-- 
Lars Eilebrecht              - Just because you're paranoid doesn't
lars@hyperreal.org            - mean they're not really after you.


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org