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
^un
I think the preceeding correction is in order...
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's assessment seems right on target to me.
Ned