The following sections from the latest (version of September 5, 1995)
HTTP 1.0 spec seem to be relevant:
I'm glad you pointed these out, because they indicate a severe
defect in the HTTP spec.
Either HTTP uses MIME content-types or it doesn't. If it does
use MIME content-types, it is fundamentally acceptable for HTTP
to have a different canonical form for such types than does MIME.
This will cause a HUGE mess for anyone who tries to do content-md5
or stronger authenticity/integrity assurances, or encryption, and
transfer such objects over both HTTP and email.
I can accept that HTTP clients need to be able to deal with
pre-MIME practice where most files were LF-delimited. (For
practical purposes, mail clients need to be able to do this
as well). But HTTP cannot redefine MIME canonical form; it's
not within its scope. At best, either the HTTP spec or the
definitions of particular content-types can include advice
about how to deal with malformed objects.
It might seem like a lot of fuss over a trivial wording change,
but the canonical form model is very important to interoperability.
It's hard enough to get people to stick to it without having
HTTP confuse the issue.
Keith