Fix issue with passed routes and provides

[mwpastore]

GitHub won't let me reopen #1095, so this replaces that PR.

This patch addresses an oddball issue. Because the provides condition both branches on and mutates response['Content-Type'], a passed route with a provides condition can interfere with the provides condition of a later route (assuming both the initial and later routes match the requested path).

Consider an example:

get '/:id', :provides => :json do
  pass if params[:id] =~ /\D/

  # some processing
end

get '/foo', :provides => :text do
  # some other processing
end

A GET request to /foo will always return 404. Why? Because the compiled provides condition of the first route will set response['Content-Type'] to application/json (here), and subsequent compiled provides conditions will short-circuit any attempts to re-examine the preferred types (here).

Workarounds:

• Don't use a :provides condition; instead, use Sinatra::Request#preferred_type to inspect the Accept header on the request and Sinatra::Base#content_type to set the Content-Type header on the response.
• Structure routes to prevent pattern overlap.
• When there is pattern overlap and matching depends on the exact format of the path, use a regular expression and params['captures'] (or a block parameter) instead of regular route parameters.
• When there is pattern overlap, combine the logic into a single route (perhaps using helpers) instead of passing to another route.
• Manually clear request['Content-Type'] before calling pass.

Solutions:

1. Clear request['Content-Type'] when throwing or catching :pass
2. Clear request['Content-Type'] in-between route iterations (calls to process_route)

It seems as though "pinning" the Content-Type of the response in before filters is a documented (or at least test-driven) feature, so clearing the Content-Type in-between calls to process_route or while throwing or catching a pass is not a solution to this problem.

This PR implements a compromise solution where if the Content-Type is set while the before filters are being applied, use it as the Content-Type of the response (i.e. it becomes a route selector), otherwise clear the Content-Type in-between calls to process_route.

[zzak]

Ok, I'll need some time to look into this, thanks for your explanation!

[zzak]

@mwpastore Could you review this after the mustermann merge, and either close it or rebase it to suit your needs? Thanks!

[mwpastore]

Will do!

[namusyaka]

@mwpastore Could you rebase this branch?