Re: security impact of dropping charset default

I don't hear anyone arguing that this should generate extra  
requirements for proxies (and I have trouble believing that any  
interop problem that's limited to the consumers would be best fixed by  
intermediaries).

Let's call this issue closed as outlined, including the addition of  
some media type-generic text in security considerations regarding  
content sniffing, on the grounds that it's a problem partially caused  
by HTTP's previous meddling in this area. If later in the process* we  
find that we have a surfeit of implementation advice, we can explore  
Larry's idea of a BCP implementation guide.

Make sense?

Cheers,

* That may happen at any time; it's just a separate discussion.


On 24/01/2008, at 7:21 PM, Adrien de Croy wrote:

>
>
> Mark Nottingham wrote:
>>
>> Are you saying that you're against adding a sentence or two to  
>> Security Considerations about this issue? So far, I've seen pretty  
>> strong support for doing so from a variety of people.
>
> I'm not against warning people about security issues, however I  
> think HTTP needs to take a stand with respect to where the  
> boundaries of its responsibility lie.  E.g. by making comment on  
> security issues unrelated to the protocol itself, it should take  
> pains to avoid being seen to be accepting any responsibility for  
> what happens to content whilst being processed by a user agent.
>
> Such warnings would perhaps be best put in another place, i.e  
> guidelines for content processing of UAs.  Such a document certainly  
> I would support being referenced by the HTTP RFC.
>
> If this is the only issue, then it could be expedient to cover it in  
> HTTP RFC, but I'd make it clear that it's nothing to do with HTTP  
> itself.  If it's not the only issue then where to draw the line?
>
> My POV is one of a proxy developer.  For UA or server developers,  
> they are forced anyway to deal with these issues as part of other  
> non HTTP (protocol) functions in their products.  UAs already  
> heuristically surmise content types and character sets even  
> regardless of (what should be MIME-) headers (in many cases done to  
> cope with poorly configured servers).  Servers likewise have a human  
> somewhere telling them or setting rules for content type and  
> possibly char set for the resources they serve.
>
> Proxies don't have this luxury.  They can only realistically forward  
> entity headers untouched.  I'd hate this charset issue to become a  
> requirement for proxies to sanitize entity headers.
>
> Regards
>
> Adrien
>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 30 January 2008 09:48:26 UTC