Re[2]: Straw-man for our next charter


We see this problem a lot at the gateway.  We have processing agents 
that only want to process say text/html, and really don't like getting 
streamed MP4s labelled as text/html by some brain-dead server

But in the end, where does the server get the C-T from?  Most just do a 
map lookup on file extension.

Even if we tried to push the meta-data into the resource itself, so it 
could be specified by the actual author (think about the hosted site, 
where the site maintainer has no control over content types the server 
will send, or not easily), then how do we trust that information?  Some 
attacker can label whatever content as whatever type if they can find 
some purpose to do so.

In the end, I think it basically makes Content-Type largely unreliable. 
  I don't see this changing with 2.0 (at least not properly), unless we 
introduce the concept of trust - either sign content by someone 
vouching for its type, or run RBLs of known bad servers.

Do we even need C-T if clients are sniffing anyway?

Adrien

------ Original Message ------
From: "Larry Masinter" <masinter@adobe.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 29/07/2012 3:01:08 a.m.
Subject: RE: Straw-man for our next charter
>The sniffing I was in particular hoping to stop is content-type sniffing.
>http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03
>
>" Many web servers supply incorrect Content-Type header fields with
>  their HTTP responses.  In order to be compatible with these servers,
>  user agents consider the content of HTTP responses as well as the
>  Content-Type header fields when determining the effective media type
>  of the response."
>
>If browsers suddenly stopped sniffing HTTP/1.1 content, it would break existing web sites, so of course the browser makers are reluctant to do that.
>
>However, if it was a requirement to supply a _correct_ content-type header for HTTP/2.0, and no HTTP/2.0 client sniffed, then sites upgrading to HTTP/2.0 would fix their content-type sending (because when they were deploying HTTP/2.0 they would have to in order to get any browser to work with them.)
>
>Basically, sniffing is a wart which backward compatibility keeps in place. Introducing a new version is a unique opportunity to remove it.
>
>The improved performance would come from having to look at the content to determine before routing to the appropriate processor.
>
>Larry
>
>
>-----Original Message-----
>From: Amos Jeffries [mailto:squid3@treenet.co.nz]
>Sent: Friday, July 27, 2012 11:53 PM
>To: ietf-http-wg@w3.org
>Subject: Re: Straw-man for our next charter
>
>On 28/07/2012 6:39 p.m., Larry Masinter wrote:
>
>>
>>re changes to semantics: consider the possibility of eliminating
>>"sniffing" in HTTP/2.0. If sniffing is justified for compatibility
>>with deployed servers, could we eliminate sniffing for 2.0 sites?
>>
>>It would improve reliability, security, and even performance. Yes,
>>popular browsers would have to agree not to sniff sites running 2.0,
>>so that sites wanting 2:0 benefits will fix their configuration.
>>
>>Likely there are many other warts that can be removed if there is a
>>version upgrade.
>>
>
>
>Which of the several meanings of "sniffing" are you talking about exactly?
>
>AYJ
>
>
>
>

Received on Sunday, 29 July 2012 23:00:10 UTC