- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 12 Nov 2010 14:31:05 +1100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>, Adam Barth <ietf@adambarth.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 UTC