> On 3 May 2017, at 4:03 pm, Julian Reschke <julian.reschke@xxxxxx> wrote: > > "Need to"? > > "Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous." -- <https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.2.5.p.9> > > So in RFC 7230 this is truly OPTIONAL. That's correct. The attitude that we took in the HTTP specs was that there are so many possible use cases for HTTP, we can't constrain their error handling, unless it's a serious security or interop issue. The problem is that many people want close compatibility with the error handling of the biggest HTTP clients -- browsers. We talked about defining a profile of HTTP for them; it's currently being written as Fetch (but not in the IETF). When we do RFC723xbis, we might want to reconsider whether this was a good path to take. Regards, -- Mark Nottingham https://www.mnot.net/