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

[Bug 848] Content Negotiation (or MIME Types)

From: <bugzilla@wiggum.w3.org>
Date: Tue, 11 Sep 2007 20:46:34 +0000
CC:
To: www-validator-cvs@w3.org
Message-Id: <E1IVCd0-0006cy-8M@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=848


sierkb@gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sierkb@gmx.de




------- Comment #2 from sierkb@gmx.de  2007-09-11 20:46 -------
(In reply to comment #1)
> This bug is invalid, quoting from the Bible (RFC 2616 - 14.1):
> 
> "If no Accept header field is present, then it is assumed that the client
> accepts all media types. If an Accept header field is present, and if the
> server cannot send a response which is acceptable according to the combined
> Accept field value, then the server SHOULD send a 406 (not acceptable)
> response."
> 
> So sending no header is fine, it's the same as */*, thus it accepts everything,
> and f you want that to mean application/xhtml+xml then so be it.
> 
> I realise the bug is hugely old but it's not marked as resolved so I thought I
> should point this out.
> 

Please read carefully Bug #18 and Bug #785 and their comments and the
appropriate discussion on www-validator.w3.org. Maybe then you will
acknowledge, that it absolutely makes sense to either send a *reasonable*
HTTP_ACCEPT header field or tunnel transparently the client's accept header
information rather than just offering an empty or */* HTTP_ACCEPT header field.
Because discussion isn't finally closed on this issue and the patch proposed on
Bug #18 hasn't found its way into the CVS trunk, from my point of view it makes
sense to let Bug #848, Bug #18 and Bug #785 still be open.
Received on Tuesday, 11 September 2007 20:46:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:08:28 UTC