On 3 May 2017, at 4:03 pm, Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)de> 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/