从Sinatra调用Sinatra会产生与外部请求不同的结果

在这里提出我的问题。 所以我试图使用这个进行智能重定向：

get "/category/:id/merge" do #... setting @catalog_id and category call env.merge("PATH_INFO" => "/catalog/#{@catalog_id}/category/#{category.id}", "REQUEST_METHOD"=>"PATCH","QUERY_STRING"=>"merge=1") status 200 end 

但是当我查看日志时，我看到的东西不仅令人沮丧，而且完全荒谬：

 # this one is from internal call I, [2013-03-21T15:55:54.382153 #29569] INFO -- : Processing GET /catalog/1/category/2686/merge I, [2013-03-21T15:55:54.382239 #29569] INFO -- : Parameters: {} ... I, [2013-03-21T15:55:54.394992 #29569] INFO -- : Processing PATCH /catalog/1/category/2686 I, [2013-03-21T15:55:54.395041 #29569] INFO -- : Parameters: {"merge"=>"1"} I, [2013-03-21T15:55:54.395560 #29569] INFO -- : Processed PATCH /catalog/1/category/2686?merge=1 with status code 404 I, [2013-03-21T15:55:54.395669 #29569] INFO -- : Processed GET /catalog/1/category/2686/merge with status code 200 # this one is a direct request I, [2013-03-21T15:56:36.246535 #29588] INFO -- : Processing PATCH /catalog/1/category/2686 I, [2013-03-21T15:56:36.246629 #29588] INFO -- : Parameters: {"merge"=>"1"} ... I, [2013-03-21T15:56:36.286216 #29588] INFO -- : Processed PATCH /catalog/1/category/2686?merge=1 with status code 204 

内部404请求的主体只是Sinatra的标准404错误页面。 他怎么能直截了当地告诉我他不知道这条路线，如果我发现他服务的url与可接受的204完全相同？

更新当我将REQUEST_METHOD改为GET时，它变得更加刺激 – 就像一个魅力。

 I, [2013-03-21T17:09:37.718756 #3141] INFO -- : Processing GET /catalog/1/category/2686/merge I, [2013-03-21T17:09:37.718838 #3141] INFO -- : Parameters: {} ... I, [2013-03-21T17:09:37.735632 #3141] INFO -- : Processing GET /catalog/1/category/2686 I, [2013-03-21T17:09:37.735678 #3141] INFO -- : Parameters: {"merge"=>"1"} ... I, [2013-03-21T17:09:37.773033 #3141] INFO -- : Processed GET /catalog/1/category/2686?merge=1 with status code 200 I, [2013-03-21T17:09:37.773143 #3141] INFO -- : Processed GET /catalog/1/category/2686/merge with status code 200