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

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