Re: security impact of dropping charset default

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

Received on Thursday, 24 January 2008 08:18:44 UTC