Subject: #186: Document HTTP's error-handling philosophy

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 May 2011 12:09:42 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/186>

Straw-man proposal: replace "Requirements" sections (in all parts) with the following.

> Conformance and Error Handling
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
> 
> This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See [ref to Terminology] for a definitions of these terms.
> 
> An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable.
> 
> This document also uses ABNF to define valid protocol elements. In addition to the prose requirements placed upon them, Senders MUST NOT generate protocol elements that are invalid.
> 
> Unless noted otherwise, Recipients MAY take steps to recover a usable protocol element from an invalid construct, and SHOULD NOT reject the message outright. However, HTTP does not define specific error handling mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the Content-Type header doesn't match the body, whereby in a systems control protocol using HTTP, this type of error recovery could lead to dangerous consequences.

Note that this removes the "conditionally compliant" level of conformance; i.e., SHOULD is no longer overloaded, and returns to is original RFC2119 semantic of identifying requirements that can be violated for reasonable reasons (see also <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/271>, which proposes that we try to enumerate those reasons wherever possible).

That's a fairly big change. I'd argue that "conditional compliance" doesn't promote interop and should be dropped. Thoughts?

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 May 2011 10:26:05 +0200

>> This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gatewa…

Would this sentence be the same in all parts?

>> Unless noted otherwise, Recipients MAY take steps to recover a usable protocol element from an invalid construct, and SHOULD NOT reject the message outright. However, HTTP does not define specific…

We have a similar sentence in the Content-Disposition spec, which 
resulted in an IESG comment because of the MAY/SHOULD NOT.

Maybe this needs clarification.

Also here's a SHOULD NOT where we don't document when it might be ok to 
break it (for instance, in a validator).

"where the Content-Type header doesn't match the body"... This is 
misleading, because there's no way to "match it" against an octet 
stream. We either need to rephrase this or pick a different example.

> Note that this removes the "conditionally compliant" level of conformance; i.e., SHOULD is no longer overloaded, and returns to is original RFC2119 semantic of identifying requirements that can be violated for reasonable reasons (see also<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/271>, which proposes that we try to enumerate those reasons wherever possible).
>

It *is* a big change, and getting all the changes done right will be 
quite some work.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 May 2011 10:51:01 +1000

> Would this sentence be the same in all parts?

Good catch; we'd have to tailor (likely one version for p1, one for the rest?).

> We have a similar sentence in the Content-Disposition spec, which resulted in an IESG comment because of the MAY/SHOULD NOT.
> 

IIRC I took this from C-D post-IESG, so hopefully it will avoid that.

> Also here's a SHOULD NOT where we don't document when it might be ok to break it (for instance, in a validator).
> 
> "where the Content-Type header doesn't match the body"... This is misleading, because there's no way to "match it" against an octet stream. We either need to rephrase this or pick a different example.

Ack.

> It *is* a big change, and getting all the changes done right will be quite some work.

Yes, but I think it's worth doing. I'm willing to do the bulk of the review and suggestions, if people are willing to review them.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 May 2011 08:39:50 +0200

> Good catch; we'd have to tailor (likely one version for p1, one for the rest?).

Probably.

> IIRC I took this from C-D post-IESG, so hopefully it will avoid that.

The difference here is that C-D only deals with invalid header field 
values. It's pretty clear that an invalid header SHOULD NOT stop 
processing of the other parts of a message.

In HTTP, we need to consider more things, such as errors that make the 
message framing invalid (status line broken, content-length 
inconsistent), non-sense data (status code < 100 or >= 600, etc).

> Yes, but I think it's worth doing. I'm willing to do the bulk of the review and suggestions, if people are willing to review them.

Will do :-)

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 May 2011 15:16:25 +1000

>> Yes, but I think it's worth doing. I'm willing to do the bulk of the review and suggestions, if people are willing to review them.

Also, I think the tasks are separable -- i.e., we can change the "conditional compliance" language and then do a separate audit of the SHOULDs to make sure they're sensible / contextualised.

Regards,