"HTTP for Web Browsers and Servers"

What do you think about a separate document for "HTTP for Web Browsers and
Servers" that talks about charset and EOL for HTML and text types, warnings,
login dialogs, etc.?

Target BCP instead of (Draft) Standard.

It would be a way of removing some of these topics from the HTTP standard
while keeping them as IETF official specifications.

Larry


> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
> On Behalf Of Adrien de Croy
> Sent: Thursday, January 24, 2008 12:21 AM
> To: Mark Nottingham
> Cc: HTTP Working Group
> Subject: 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 15:16:23 UTC