httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: general/4213: .htaccess skipped when IE5 has friendly error messages set
Date Fri, 09 Apr 1999 12:39:54 GMT
In a message dated 99-04-09 02:56:42 EDT, Greg Stein appended thread...

> > It appears ( I emphasize 'appears' for any MS'ers reading this thread' )
>  > IE5 assumes that anything less than 512 bytes coming back as an
>  > error response isn't worth displaying so that's when it puts up
>  > it's default 'response' screens.
>  > 
>
>  As somebody pointed out earlier, it is entirely within the purview of
>  the client to make this decision (per the RFCs). People are simply
>  taking the status quo (display whatever) as the "way it should be".
>  
>  Personally, I'll take IE5's side of this. There are quite a few times
>  when I get bare-bones 404 pages, or 500's or a couple others. If IE5
>  wants to put up something nicer... then fine.
>  
>  For the big sites that are trying to put up a nice page about "sorry,
>  that wasn't found. you can search for it <here> or ...", well... those
>  pages should be large enough. I think IE5 is using a pretty smart
>  heuristic to balance between filtering out "legacy" errors and producing
>  (hopefully) more meaningful error pages for surfers.
>  
>  Cheers,
>  Greg Stein, http://www.lyra.org/

Sorry... I'm not buying what you are selling.

If it's time to come up with a good solution for presenting better error 
response
messages on the Internet then fine... let someone do it right. This sounds 
like
the hack-of-life.

If it's going to be OK for any client presentation agent to ignore valid 
informational
responses from a server because they just don't have 'enough bytes' in them 
then it's
it's also time to add a header line like 'content_is_not_to_be_discarded=yes'
or something so that it can be PREVENTED when necessary.

To me... if there is ANY valid content after the header then it's supposed to
be displayed unless there's some header instruction that tells me otherwise.
HTTP is a presentation layer protocol. That means if something is NOT
supposed to be 'presented' then the when/why should be pretty air-tight.

What if a large software company that shall remain nameless decides that
a HTTP document ( 200 response ) is not worth showing because it doesn't
have enough bytes in it? Are you saying it would be OK by you if they just
threw it on the floor and put up one of their ADS instead?

If there is nothing after the blank line indicating end of header then sure...
why not throw up some content that's readable... but there are other RFC's
around which say if there IS valid content following a 'header' then 
presentation 
agents are supposed to SHOW it.

The Web gets slower and slower every day and more and more clogged with
useless bytes ( Take a look at CNN's 67,000 byte home page and you will
see what I mean ). To require thousands of servers to re-write CGI scripts
and start padding response documents with more useless bytes just so
the content can be preserved for specific client agents is just a little too
weird for me.


Mime
View raw message