W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Content Sniffing impact on HTTPbis - #155

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 2 Jun 2009 10:04:58 -0700
Message-ID: <7789133a0906021004p50d99efbqa90b097eaa630cb3@mail.gmail.com>
To: Mark Baker <distobj@acm.org>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks the below is very helpful.


On Tue, Jun 2, 2009 at 5:41 AM, Mark Baker <distobj@acm.org> wrote:
> On Mon, Jun 1, 2009 at 4:58 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Jun 1, 2009 at 12:30 PM, Mark Baker <distobj@acm.org> wrote:
>>>> 2) specify the algorithm to use if sniffing is done by referring to
>>>> draft-abarth-mime-sniff directly.
>>> I don't think that has any place in the HTTP spec, especially as even
>>> the revised version continues to use prescriptive language that
>>> supercedes key parts of the HTTP protocol.
>> I'd like to incorporate your feedback into the draft, but the above is
>> too vague for me to act upon.  Are there specific statements you'd
>> like me to revise?
> Here they are;
> "The /sniffed type/ of a resource MUST be found as follows:"
> to;
> "The /sniffed type/ of a resource is found as follows:"
> This should be removed;
> "File extensions MUST NOT be used for determining resource types for
> resources fetched over HTTP."
> As it's clear from the algorithm that file extensions are not
> referenced, and it's HTTP's job to say what meaning is or isn't given
> to them (which, of course, is none).
> Also, this introductory claim should be removed;
> "However, if the user agent does emply[sic] a
> content sniffing algorithm, it is imperative that the algorithm in
> this document be followed exactly"
> It should suffice that the draft explains the drawbacks of not
> following the algorithm because a) the algorithm is still evolving
> (e.g. text/plain), b) if an implementor has a good reason to implement
> a different algorithm, they will, and c) the document should describe
> the algorithm, and any conformance requirements about its use should
> be left to the referrer (e.g. if the HTTP spec refers to it).
> Just for completeness' sake (removing the MUSTs), this;
> "the user agent MUST stop this
> algorithm, and assume that the /sniffed type/ of the resource is
> "text/html"."
> could be changed to "the algorithm stops and the /sniffed type/ of the
> resource representation is "text/html"
> Separately, as an editorial comment, as listed directly above, I'd
> like to see a big s/resource/resource representation/g (or just
> s/resource/representation/g as the resource is what is identified by
> the URI, not the bag-o-bits returned in an HTTP response.  I have some
> other editorial comments too, but those will have to wait until I have
> time to write them down.
> Mark.
Received on Tuesday, 2 June 2009 17:05:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC