MUST NOT lie

[martinthomson]

A sender MUST NOT generate protocol elements that convey a meaning that is known by that sender to be false.

-- https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.2.2.p.5

This doesn't seem to be enforceable in any way. This isn't really talking about whether the syntax is valid, but about the semantics, so it's easy to disavow knowledge of falsehood (my browser isn't necessary aware that me typing "the sky is pink" is false). I think that it might be better to simply observe that it is contrary to function - and possibly interests - of a sender to generate protocol elements that convey semantics that are incorrect or contrary to the interests of the sender.

Normative language implies interoperability failure if it is ever violated, and I don't think that is the case here.

[royfielding]

It is enforceable. If a sender communicates a syntactically valid construct that is deliberately misleading, then the recipient's behavior in response will be equally confusing to all parties. We saw exactly that both in the deployment of HTTP/1.1 and in the early deployment of DNT. Both resulted in interop failure, and both failures were only corrected after the standards were enforced by recipients refusing to accept invalid signals.

[reschke]

We might be talking past each other. @royfielding - could you give us a concrete example that this text is trying to rule out?

[mnot]

Or, for example, P3P, where people deliberately set false and misleading policies so that browsers wouldn't complain.

Roy, it's a nice thought, but this is the kind of regulation that's done by law, not architecture.

[royfielding]

Both laws and RFCs are defining standards of conduct. The difference with laws is sovereign enforcement, not social versus technical. In any case, this has been true of HTTP implementation (Apache httpd, for example) since 1996. A server will check for compliance based on User-Agent version match and ignore protocol signals that are known to be false or at least unreliably implemented by that sender. Browsers do the same for some servers that deliver default Content-Type settings by mistake. We consider the workarounds to be standards-compliant because of this MUST NOT. And, as I said, we enforce that ALL OF THE TIME.

[mnot]

Discussed at Feb 21 interim; add context to help readers understand why this requirement is here / important. @royfielding to PR.

[martinthomson]

Context... ?

HTTP is designed to carry information that senders know to be true. A sender that generates false information causes recipients to consume that information according to its semantics, which can produce adverse effects. Purposefully generating false information might be done with the intent of effecting actions on the part of other entities, which is not limited to protocol implementations. Any protocol element that is known to be false MAY be treated by a recipient without any regard for compliance with the protocol on the basis that the presence of (deliberate?) falsehood is not valid HTTP.

Then add an example, probably a fictitious one out of deference for the sensitivities in all the truly good examples.