W3C home > Mailing lists > Public > www-validator-cvs@w3.org > April 2007

[Bug 785] validator does not supply reasonable Accept header by default

From: <bugzilla@wiggum.w3.org>
Date: Thu, 26 Apr 2007 14:13:12 +0000
To: www-validator-cvs@w3.org
Message-Id: <E1Hh4ie-0006cx-GF@wiggum.w3.org>


------- Comment #15 from sierkb@gmx.de  2007-04-26 14:13 -------
Is there any good reason, to *not* sending an accept header at all or to send
an empty accept header?
I presume the validator to be a normal requesting client from the servers'
point of view. So the validator should provide a reasonable accept header.

Please have a look at

Per default, I serve .html with the MIME type "text/html". If a client
requests, which accepts "application/xhtml+xml", then an Apache rewrite rule
rewrites the MIME type to "application/xhtml+xml" as for instance 
http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html proposes. This solution
works very well, but not in validator 0.8 beta, which throws out a warning
about a false served media type. This warning is fully acceptable concerning
the fact, that the validator in fact seems to reseive "text/html" instead of
"application/xhtml+xml". This problem would not exist, if the Validator would
provide a reasonable accept header! If it would provide one and indicates, what
MIMEtypes it accepts, then the webserver's rules have the chance to match. At
the moment, there is no chance for such rules to match because of lacking
information from the validator. Currently the validator throws out a warning
about a problem or misconfiguration, which does not necessary apply, if the
validator would be a little more server-friendly and would provide a proper and
talking accept header.

My solution in conditionnaly rewriting the MIME type by the webserver, is a
compromise to not let the Internet Explorer out of the playground. If IE would
understand "application/xhtml+xml", I would have much less sleepless nights. In
that case, I could serve "application/xhtml+xml" per default to any XHTML
document, like the spec defines/recommends. But that is fiction so far. So
little workarounds have to be done.

I *want* to use XHTML, lastly to promote it. I intentionally *want* to use
XHTML 1.1, lastly to promote it and lastly to provide it to web browsers, who
are capable in doing their work correctly and fulfilling the standards.
And I want my documents be parsed as XML and not as SGML as far as possible.
Browsers like the Internet Explorer, who don't work correctly and don't catch
up the stabdards, have got a bad standing (at least and especially in my eyes),
and I am *not* willing to provide (or going further: foster) this bad standing
any longer. The browser vendor, especially Microsoft, *has to do* his homework
in delivering a good and reliable piece of software. Is that the intention of
the W3C QA? Don't give XHTML 1.1 real chances, because of one single web
browser out there, who can't really deal with it?

The content on my website http://sierkbornemann.de/ semantically meets XHTML
1.1. So why shouldn't I use a XHTML 1.1 DTD and the appropriate mimetype
"application/xhtml+xml" for clients, which are capable of it?
If all other web browsers but one browser (the IE) could be served with fully
compliant XHTML 1.1 including the correct MIME type, then I want to do it. If
this one browser (the IE) couldn't be served with the correct MIME type or only
could be served with minimal flaws, then it is my risk to take.

The validator should behave like a client, which is full capable of these
standards, and it should provide this information to the public in presenting a
reasonable and talking accept header to the webservers out there.
Received on Thursday, 26 April 2007 14:13:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:17:28 UTC