[5369] in www-talk@info.cern.ch
Client Compliance
daemon@ATHENA.MIT.EDU (M.J.Cox@bradford.ac.uk)
Fri Aug 26 16:39:09 1994
Date: Thu, 25 Aug 1994 18:25:31 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: M.J.Cox@bradford.ac.uk
From: M.J.Cox@bradford.ac.uk
To: Multiple recipients of list <www-talk@www0.cern.ch>
Hi.
We need some sort of "Compliance Test". Every client produced should be
able to be "certified" compliant with a particular level of HTTP and HTML
support. Either that or a big list of un-compliant clients should be
regularly posted to try to shake the authors up a bit. The Compliance level
should be sent from the client along with the standard User-Agent field.
"Hi, I'm XYZZYBrowser version 2.2, I can handle forms as long as they are
not Posted to authenticated areas and I use the file extension instead of
the mime type for working out inline images apart from that I'm compliant
with HTTP X.Y and HTML Z.X"
Why? Well I can't seem to find many browsers that actually do
everything correctly!
With all the talk recently on this list about "Expires:" HTTP headers its
interesting to see if any of the clients actually make use of this
information...
I've got a page which is constantly updated with a "refresh page" link,
to stop the page getting cached it outputs an Expires header correctly.
The majority of clients that visit me are- [1]
lynx 2.3 beta (and below) ignored expires header
WinMosaic 2.0 (alpha 2-6) ignored expires header
AirMosaic 2.5 Beta C Demo ignored expires header
Cello (0.9,1.0) ignored expires header
WinWeb a2 ignored expires header
XMosaic 2.2,2.4 doesn't cache documents anyway
So much for the expires header! (Temporary solution: put a random query
string onto the link URL each time its run)
Take POSTing a form into an Authenticated area - which can handle it and
which cant? [2]
lynx 2.3 beta yes!
XMosaic 2.4 yes!
MacMosaic 2.0.0 a2 yes!
WinMosaic 2.0 (alpha 6) crashes (blank line in mime header)
AirMosaic 2.5 Beta C Demo just been fixed (not on release version)
Cello (1.0) no authentication support
WinWeb a2 no authentication support
My application relies on the ability to post in an authenticated area,
how does my server know if the client they are using can or can't handle
it? Maybe they could look at "User-Agent".....
You might think that clients would at least get "User-Agent" right,
its amazing how many dont...
According to the specification
The first white space delimited
word must be the software product name
<field> = User-Agent: <product>+
<product> = <word> [/<version>]
<version> = <word>
FAIL - NCSA Mosaic for the X Window System/2.4 [=white space]
FAIL - MacMosaicB6 libwww2.09 [=version in product name]
FAIL - MacMosaic 2.0.0 a2 [=white space, no /]
FAIL - OmniWeb/OmniWeb 0.7.4.1 libwww/unknown [=white space]
FAIL - MacWeb/libwww/2.13 libwww/unknown [=too many /]
FAIL - WinMosaic/Version 2.0 (ALPHA 3) [=white space]
FAIL - Lynx/2.3 BETA libwww/2.14 [=Beta not part of version]
PASS - AIR_Mosaic(16bit)/v3.00.02.02
PASS - EI*Net/0.1 libwww/0.1
PASS - LII-Cello/0.9
You could argue that the User-Agent field isn't very important. But
so many clients are not fully-compliant with the standards - it's
useful to be able to tell a user of an interactive service if their
client will work at all. How? The only way is for me to have
a huge table of clients with reasons for them not being able to
handle the service
How about returning a GIF on STDOUT from a CGI script - all the clients
work apart from WinMosaic and AirMosaic which don't bother with the
mime-type for determining what to do with a file - they still use the
file extension!
---
1. I know some of the clients I mention below are in Alpha or Beta
test. A large proportion of clients visiting my site are
labelled as "alphas" and "betas", people will continue to use them
for some time.
2. Some of the problems are due to bugs in the clients and
I'm not blaming either the protocol writers or the browser
authors; we need a way of the server knowing!
Mark
Mark J Cox ---------------------- <URL:http://www.eia.brad.ac.uk/mark.html>
Industrial Technology, Bradford University, UK +44 1274 384070/fax 391333
