anchor.diff:  * *Rate Limit & quota policies*
   * *Spike arrest*
   * *Cache* - cache policy will not be testable through debug mode with in memory cache since it is created and destroyed with the api
  -* *IPFiltering* - Since calls are being executed by the gateway, you won't be able to IPFiltering your IPs directly in the debug session (IP used for the call would be 127.0.0.1 if you want to validate behavior)
  +* *IPFiltering* - Since calls are emited by the gateway itself, you will not be able to emulate a call from another IP with the debug mode (IP used to issue requests is 127.0.0.1)
   * *Health-check*
  -* *Virtual hosts* - the first host is selected
  +* *Virtual hosts* - the first host is always selected
  
positive.code: == How to Get Started With Debug Mode
  
  . link:{{ '/apim/3.x/apim_publisherguide_design_studio_create.html' | relative_url }}[Design your API^].
  . Click *Debug* tab.
  . Configure your request.
  . Click *Send* button.
  
  == How To Test Your API Concept with Debug Mode
  
  You can test your *API* through the HTTP client available in the *Debug* tab.
  
  You don't need to save or deploy the API to test your changes in the Debug Mode.
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-example-empty.png %}[Debug Mode empty example]
  
  With this client, you can call your *API*, and test and experiment with the following:
  
  * *HTTP method* lets you select the HTTP verb.
  * *Path* (and additional query parameters). _Note: The context-path of the API your are debugging is already taken into account. Path refers here to the subpath (e.g., myapi-context-path/subpath?queryparam=value)_
  * *Headers*
  * *Request body*
  
  Since the debug mode is emulating an external call to your API, it would resolve the flow as the gateway would do, you need to pass the proper path, headers and fit all conditions in order to test a specific flow.
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-example.png %}[Debug Mode example]
  
  The debug mode displays all policies in a vertical timeline so you can easily visualize the exact order in which they are executed.
  
  === Different state for policies :
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-legend.png %}[Debug Mode legend]
  
  * *executed* - the policy has been executed properly
  * *skipped* - the policy was conditional and hasn't been executed, you can see the condition evaluation in the policy information panel
  * *error* - an error occurred during policy execution, you can see more information in policy panel
  
  By clicking on a specific policy in the timeline, you can see information for input/output for :
  
  * header
  * context attributes
  * body
  
  There is three colors in inspector :
  * red stands for deletion
  * orange stands for edition
  * green stands for addition
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-inspector.png %}[Debug Mode inspector]
  
  
negative.code: 
  ==== How to interpret ?
  
  The order in which the policies appear in the timeline reflects the exact order in which they have been executed by the gatewau at runtime. 
  
  Note that *this order may differ* from the order in which policies where placed in the Policy Studio during the design phase. 
  
  This is due to a performance optimization applied at runtime on the the policy chain. The gateway always executes policies interacting with the HTTP Header part of the request (onRequest, onResponse) before policies interacting with the body part of the request (onRequestContent, onResponseContent).
  
  Also, a policy may appear twice in the timeline if it interacts with both the head and the body part of the request.
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-policy-chain.png %}[Policies execution chain order]
  
  