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


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 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:44 UTC