Re: content inspection in absence of media type, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24

Mark Nottingham <> Thu, 31 October 2013 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D764021E80BB; Wed, 30 Oct 2013 20:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.694
X-Spam-Status: No, score=-104.694 tagged_above=-999 required=5 tests=[AWL=-2.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4HrO5PMwto2O; Wed, 30 Oct 2013 20:31:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 65E0921F9DE9; Wed, 30 Oct 2013 20:31:41 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 39FA922E2CA; Wed, 30 Oct 2013 23:31:31 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: content inspection in absence of media type, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 31 Oct 2013 14:31:28 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: S Moonesamy <>
X-Mailer: Apple Mail (2.1510)
Cc: Julian Reschke <>,,,,
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 03:31:47 -0000


Consensus around this text was particularly hard-won; unless there is a very good reason to make a change, I'd rather not risk falling into that rat-hole again.


On 31/10/2013, at 2:49 AM, S Moonesamy <> wrote:

> Hi Julian,
> At 07:12 29-10-2013, Julian Reschke wrote:
>> I consider that sentence to be useless - if I can't detect the type, what else but "treating as arbitrary data" is left as an option anyway?
> I'll comment below.
>> I still don't get what the issue is :-)
> My preference is not to generate material which create more work for you.  It's better not to pursue this one. :-)
>> The subsequent text is:
>> "In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used."
>> Do you think this is insufficient, or that it needs to move to a different part of the spec?
> The subsequent text is, to put it simply, about an operational issue and security considerations.  The recommendation in Section is to generate a Content-Type header field if the server knows the media type.  There are cases when the server does not know the media type.  In such cases the server sends the client "application/octet-stream".  There is where the user has to determine whether the server is operated by good person or a bad person (re. arbitrary data).  The user relies on the browser to perform some magic to determine that.  That magic does not always work well.
> If it was my decision (and it is not) I would discuss about this under Security Considerations and mention that content sniffing can cause security problems.  Please note that there are different alternatives to tackle the issue.
> Regards,
> S. Moonesamy 

Mark Nottingham