Caddy version: v2.7.4 h1:J8nisjdOxnYHXlorUKXY75Gr6iBfudfoGhrJ8t7/flI=

The handle_response documentation states:

When a response handler is invoked, the response from the backend is not written to the client, and the configured handle_response route will be executed instead, and it is up to that route to write a response. If the route does not write a response, then request handling will continue with any handlers that are ordered after this reverse_proxy.

Given this, I would expect a empty handle_response route to cause the request handling to continue with the next handler. But that doesn't appear to be the case. Furthermore, the behavior appears to be inconsistent and dependent upon the presence or absence of other directives.

Reproductions

In all the examples below, I am making a request to http://localhost.

1. Given this Caddyfile, I'd expect the response to be handled by the handle_response @ok route and then continue to the respond 299 directive. However the actual response is a 499.

   {
       auto_https off
       order respond after reverse_proxy
   }
   
   :80 {
       reverse_proxy example.com {
           header_up Host "example.com"
   
           @ok status 200
           handle_response @ok {
           }
   
           handle_response {
               respond 499
           }
       }
   
       respond 299
   }

2. If I add a useless directive to the handle_response @ok route, then that route is used as expected. The actual response here is a 299

   {
       auto_https off
       order respond after reverse_proxy
   }
   
   :80 {
       reverse_proxy example.com {
           header_up Host "example.com"
   
           @ok status 200
           handle_response @ok {
               skip_log
           }
   
           handle_response {
               respond 499
           }
       }
   
       respond 299
   }

3. If I remove the handle_response route, then I'd expect to continue to the respond 299 directive. But the actual response here is the response from the upstream exmaple.com request. This is particularly surprsing since copy_response is not used anywhere.

   {
       auto_https off
       order respond after reverse_proxy
   }
   
   :80 {
       reverse_proxy example.com {
           header_up Host "example.com"
   
           @ok status 200
           handle_response @ok {
           }
       }
   
       respond 299
   }