This patch addresses an oddball issue that was the source of much hair-pulling this evening. 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 with an Accept header of application/json,text/plain 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 :pass
2. Clear request['Content-Type'] when catching :pass
3. Clear request['Content-Type'] in-between route iterations (maybe?)

This patch implements solution 1 but I'm interested in your feedback.

Thank you in advance!