Request :content-type SPEC inconsistency with several adapter implementations about ring HOT 7 CLOSED

The :content-type field was originally designed (I believe) to pull information from the getContentType method on Java servlet request objects. It's never been a key I've considered to be that useful, but it cannot be removed at this point without introducing backward compatibility. Perhaps a clarification of the SPEC is in order? @mmcgrana do you have any thoughts on this?

I think the multipart-params middleware should absolutely use the raw header. It's the most predictable way of doing so.

from ring.

Yikes, I honestly don't know what I was thinking there /:

It was indeed originally designed to pull from getContentType, but
according to @aroemers in Jetty (the original adapter) this is just a
copy of the Content-Type header verbatim which isn't useful at all.

I agree that accessing the header directly is the most appropriate
approach for middleware.

Changing the semantics of the Jetty adapter seems a bit risky to
me, especially since the semantics weren't well-specified before.
Perhaps we should move to deprecate the field in the spec? This
could be like Clojure core's deprecation approach: note things as
deprecated but avoid removing / changing them if possible.

A later major version of ring could perhaps remove this field and
point to a shim middleware that injects it based on headers for
compatability with older libraries.

from ring.

That sounds a reasonable solution to me. Might I suggest we also deprecate :content-length and :character-encoding at the same time?

from ring.

Sounds plausible to me. Might also be a good topic for the mailing list?

from ring.

I posted a mailing list topic.

The SPEC actually defines those three keys as optional anyway, so in theory we shouldn't be relying on them to exist in ring-core anyway.

from ring.

These keys have been deprecated in the 1.2 draft SPEC as of 55416cb.

Additionally, ring-core has been updated to avoid using these keys, and additional functions have been introduced to ring.util.request to allow uses to pull content-type, content-length and the character-encoding from the request without using the deprecated keys.

from ring.

Great work, thanks.

from ring.