W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: "HTTP for Web Browsers and Servers"

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 30 Jan 2008 20:49:34 +1100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <6E3B22B3-2074-466D-89A5-48D3E0C77C48@mnot.net>
To: Larry Masinter <LMM@acm.org>

Do you think that it would be able to take a substantial amount of the  
material in 2616 into a separate document?

My concern is that writing such a beast from scratch is a pretty big  
undertaking, when we already have BIS and the security property docs  
on our plate. Are you volunteering? :)


On 25/01/2008, at 2:14 AM, Larry Masinter wrote:

>
> 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
>>
>
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 30 January 2008 09:50:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:36 GMT