W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Content-Disposition next steps

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 12 Nov 2010 14:31:05 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, Adam Barth <ietf@adambarth.com>
Message-Id: <7825A532-141A-4A0B-9BED-83201ECFE71D@mnot.net>
To: Maciej Stachowiak <mjs@apple.com>
Doubtful, because there are always going to be non-browser cases where other behaviours make sense.

I've raised it before, but there's a need out there for a "what is a browser" spec that pulls in all of the different specs a browser has to conform to. Doing that would give an opportunity to also say what optional features have to be implemented by a browser (such as this).

Regards,


On 12/11/2010, at 6:13 AM, Maciej Stachowiak wrote:

> 
> On Nov 9, 2010, at 12:47 AM, Julian Reschke wrote:
> 
>> On 09.11.2010 02:53, Mark Nottingham wrote:
>>> ...
>>>> - there's disagreement about whether we should require specific handling of invalid messages
>>> 
>>> Actually, I think we have agreement that it should *not* be required; the current discussion is whether it's useful to specify optional handling, and where that should be done. Does anyone disagree (i.e., think it should be required as part of HTTP)?
>> 
>> I agree it should not be required.
>> 
>> (Note that even HTML5 allows recipients to reject non-conforming HTML)
> 
> Optional defined error recovery seems like a good step, so I am hesitant to rock the boat, but would it be a plausible future direction to say implementations must either use the defined error recovery or reject (with a clearly defined meaning of reject, i.e. completely ignore that header field, or discard the whole message, or whatever)?
> 
> Regards,
> Maciej
> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 12 November 2010 03:31:37 GMT

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