- From: Robert Burns <rob@robburns.com>
- Date: Fri, 17 Aug 2007 20:47:58 -0500
- To: Sam Ruby <rubys@us.ibm.com>
- Cc: Dan Connolly <connolly@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
Hi Sam, On Aug 17, 2007, at 4:09 PM, Sam Ruby wrote: > > Dan Connolly wrote: >> The Feed/HTML sniffing review comment reminded me... since >> the scope of the HTML 5 spec overlaps with the scope >> of the HTTP spec, we should get review by the IETF/HTTP >> community (including the W3C TAG). >> I just packaged the relevant section >> http://www.w3.org/html/wg/html5/#content-type-sniffing >> as an Internet Draft-to-be, with this introduction: >> ---8<--- >> The HTTP specification[HTTP], in section 14.17 Content-Type, says The >> Content-Type entity-header field indicates the media type of the >> entity-body sent to the recipient. >> The HTML 5 specification[HTML5] specifies an algorithm for >> determining >> content types based on widely deployed practices and software. >> These specifications conflict in some cases. (@@ extract a test cases >> from Step 10 of Feed/HTML sniffing (part of detailed review of >> "Determining the type of a new resource in a browsing context")) >> According to a straightforward architecture for content types in the >> Web[META], the HTTP specification should suffice and the HTML 5 >> specification need not specify another algorithm. But that >> architecture >> assumes that Web publishers (server adminstrators and content >> developers) reliably label content. Observing that labelling by Web >> publishers is widely unreliable, and software that works around these >> problems is widespread, the choices seem to be: >> * Convince Web publishers to fix incorrectly labelled Web >> content >> and label it correctly in the future. >> * Update the HTTP specification to match widely deployed >> conventions captured in the HTML 5 draft. >> While the second option is unappealing, the first option seems >> infeasible. >> The IETF community is invited to review the details of the HTML 5 >> algorithm in detail. > > On this subject, I have a request. I'll phrase it as a mild rant, > but I fully understand why firefox made the change that it did. > > The following is a test case: > > http://feedvalidator.org/testcases/atom/1.1/brief-noerror.xml > > The response contains the content type of application/xml as I > wanted to view the data in an XML parse tree. Even though what I > sent was per spec, and used to work, firefox decided that the need > to emulate IE's broken behavior was more important than respecting > my expressed wishes. > > While I don't expect this to be fixed, I would like to request that > there be some parameter (like, "application/xml; damnit") which > indicates that I think I know what I'm doing and would appreciate > being treated like an adult. I'm getting a response header of text/xml not application/xml. I may not understand what you're trying to accomplish here, but I thought the application/xml MIME type was meant to solve the problem with the text/xml MIME type. The response header: HTTP/1.1 200 OK Date: Sat, 18 Aug 2007 01:44:23 GMT Server: Apache Last-Modified: Fri, 13 Apr 2007 13:10:42 GMT ETag: "d3c283-2d2-3b057880" Accept-Ranges: bytes Content-Length: 722 Vary: Accept-Encoding,User-Agent Connection: close Content-Type: text/xml Take care, Rob
Received on Saturday, 18 August 2007 01:52:11 UTC