rails/rails — pull request #13409 by carlosantoniodasilva (2013-12-19 19:28:31+00:00)
Title: Move the null mime type to request.format

TLDR: always return an object that responds to the query methods from request.format, and do not touch Mime::Type[] lookup to avoid bugs.

---

Long version:

The initial issue was about being able to do checks like request.format.html? for request with an unknown format, where request.format would be nil.

This is where the issue came from at first in #7837 and #8085 (merged in cba05887dc3b56a46a9fe2779b6b228880b49622), but the implementation went down the path of adding this to the mime type lookup logic.

This unfortunately introduced subtle bugs, for instance in the merged commit [a test related to send_file had to be changed](https://github.com/rails/rails/commit/cba05887dc3b56a46a9fe2779b6b228880b49622#diff-00933fde66bed68a3d2ec7400b2c0b79L147) to accomodate the introduction of the NullType.

Later another bug was found in #13064, related to the content-type being shown as `#` for templates with localized extensions but no format included. This one was fixed in #13133, merged in 43962d6ec50f918c9970bd3cd4b6ee5c7f7426ed.

Besides that, custom handlers were not receiving the proper template formats anymore when passing through the rendering process, because of the NullType addition. That was found while migrating an application from 3.2 to 4.0 that uses the Markerb gem (a custom handler that generates both text and html emails from a markdown template).

---

This changes the implementation moving away from returning this null object from the mime lookup, and still fixes the initial issue where request.format.zomg? would raise an exception for unknown formats due to request.format being nil.

It is worth noticing that [all tests](https://github.com/rails/rails/commit/cba05887dc3b56a46a9fe2779b6b228880b49622#diff-cd75c7c20db7e5ab5d2534f7f28227b8R594) that [were added](https://github.com/rails/rails/commit/43962d6ec50f918c9970bd3cd4b6ee5c7f7426ed#diff-38f248f3c2154919879939f3fd0dee42R38) by this "feature" have been kept and are working fine. If that's acceptable I'll backport to 4-0-stable accordingly.