[thelist] Browser sniffing (Was: Safari details + UA string)

[Hassan Schroeder]

Peter-Paul Koch wrote:

>> Making decisions based on the UA string isn't a good idea, but just as
>> you'd fork DOM & CSS based on the UA's capabilities, looking at
>> HTTP_ACCEPT is a valid way to determine how to serve documents, IMO.
>
> I'd say 'which documents to serve', but otherwise you're correct. Using
> HTTP_ACCEPT is no browser detect, since HTTP_ACCEPT gives exactly the
> information you need to make an informed decision about which documents to
> serve.

OK, this has been a puzzle to me for a long time -- if HTTP_ACCEPT
is intended to provide the mime-types the browser understands, why
the f*** do all browsers return */* ??  As in what*ever??

Windows sample strings {

Moz 1.1 text/xml,application/xml,application/xhtml+xml,text/html;
	q=0.9,text/plain;
	q=0.8,video/x-mng,image/png,image/jpeg,image/gif;
	q=0.2,text/css,*/*;q=0.1

IE 5.5  image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Op7  	text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

Amaya 6.4 */*;q=0.1,image/svg+xml,application/mathml+xml,application/xhtml+xml

Lynx 2.8 text/html, text/plain, text/sgml, video/mpeg, image/jpeg,
	image/tiff, image/x-rgb, image/png, image/x-xbitmap,
	image/x-xbm, image/gif, application/postscript, */*;q=0.01

Xemacs/w3 multipart/alternative, multipart/mixed, multipart/*,
	application/x-x509-ca-cert, application/x-x509-user-cert,
	application/octet-stream, application/dvi, application/emacs-lisp,
	application/x-tar, application/x-latex, application/x-tex,
	application/latex, application/tex, application/texinfo,
	application/zip, application/pdf, application/postscript,
	audio/x-mpeg, audio/*, message/rfc-*822, image/x-xwd,
	image/x11-dump, image/windowdump, image/*, text/plain,
	text/enriched, text/html, video/mpeg, x-world/x-vrml,
	archive/tar

} and note that IE doesn't even explicitly say it accepts text/html,
and Lynx (a text browser) accepts images and video (!).

OK, the xemacs/w3 is just for comparison, since I'm sure virtually
no one uses it :-) but it's also the only one to *not* send */*

Still, what exactly is a site developer supposed to derive from this
apparently misleading mess?

/*
Accept header ref for anyone interested is:
   <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1>
  */
--
Hassan Schroeder ----------------------------- hassan at webtuitive.com
Webtuitive Design ===  (+1) 408-938-0567   === http://webtuitive.com

                           dream.  code.