Re: Content Sniffing impact on HTTPbis - #155

On Tue, Jun 2, 2009 at 5:41 AM, Mark Baker <distobj@acm.org> wrote:
> 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:"

Fixed.

> 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).

I've changed this to a note explaining why using file extension to
determine the media type of HTTP resources is a bad idea.

> 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).

I've softened this a bit and made it just a lead in to the explanation
of why using a divergent algorithm is a bad idea.  If you see a better
way to bridge the first sentence (UAs shouldn't sniff) to the example
(using a different algorithm causes problems), please let me know.

> 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"

Fixed.

> 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.

Ugg.  That's super wordy.  Is there really not a better way to refer
to the thing contained in an HTTP response?  Would entity-body be
appropriate?

Adam

Received on Friday, 5 June 2009 08:31:14 UTC