W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: review of content type rules by IETF/HTTP community

From: Robert Burns <rob@robburns.com>
Date: Fri, 17 Aug 2007 20:47:58 -0500
Message-Id: <D3E96DDA-FFEB-45A3-B5AF-5D098EF62929@robburns.com>
Cc: Dan Connolly <connolly@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
To: Sam Ruby <rubys@us.ibm.com>

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,
Received on Saturday, 18 August 2007 01:52:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC