tl;dr;

Allow the formatter middleware to bypass serialization of response bodies when the status indicates there is no content.

Background

#1162 describes a scenario where OPTIONS requests and redirects can raise exceptions when content types are limited to those that don't consider '' as valid or are not prepared to handle it. The specific example given involved content types being limited (or set by default) to XML. '' is not consider to be valid XML and as such results in an error when serialization is attempted.

A resolution was proposed to handle this in the formatters by checking the request method. It seems - and was suggested - that this opens up the scope of concern for the formatters too much and I agree. Additionally, it places a burden on all custom formatters to account for responses intended to have no content - like the OPTIONS request in question.

Process

I initially referenced the RFC to determine the best course of action, and found this:

A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".

This indicates that while the specification for a response body is not defined in the RFC, it is most certainly allowed given that the status code is 200 and should ideally be accounted for. This led me to begin ensuring that OPTIONS requests could be serialized appropriately by the formatter middleware, which led to ideas involving a special representation of no content that could be checked conditioned there.

When thinking through this and beginning to write some tests, I found that I was unable to get the content type to persist in the response. This led me to Rack where I found this:

 if [204, 205, 304].include?(status.to_i)
   header.delete CONTENT_TYPE
   header.delete CONTENT_LENGTH
   close
   [status.to_i, header, []]
 else
   [status.to_i, header, BodyProxy.new(self){}]
 end

After some additional digging I found that Rack::Lint takes it a step further and does not consider a response to be valid if it has content information and it's status code is included in Rack::Utils::STATUS_WITH_NO_ENTITY_BODY.

• https://github.com/rack/rack/blob/master/lib/rack/lint.rb#L659
• https://github.com/rack/rack/blob/master/lib/rack/lint.rb#L673

Proposal

Using these observations, my proposal here is to condition the formatter middleware to look for response statuses that indicate a content body in not appropriate and make the decision to bypass serialization.

This allows for both OPTIONS routes that return a 200 with a serialized body based on normal content negotiation, and for the default OPTIONS route that is auto-generated by the framework which returns a 204 and no content and does add additional concerns to each default and custom formatter.

Additionally, I believe this addresses the second issue in #1162 involving a similar issue with redirects.