Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Anatomy and Flow of an HTTP Request / Response

    1. The client issues an HTTP request, either from a web browser, script or tool, to an IP or hostname that resolves to a WebApp Secure system (it may pass through firewalls and/or load balancers on the way).
    2. This request is initially handled by a routing proxy that either:
      • In the case of static files, such as CSS, Javscript, or binary content like images, proxies directly to the backend server and returns the resource.
      • In the case of URIs added to the proxy exclusions list (engine.proxy.exclusions parameter), proxies directly to the backend server and returns the page or resource.
      • In the case of all other URIs, proxies to the security engine.

      This proxy also performs a regular-expression-based match on the hostname to determine which configuration options to apply to the request, based on your application settings. In the event of no match, the global defaults are used.

    3. If the request reaches the security engine, several important managers parse it:
      1. Location Manager–The location manager parses the incoming IP address, as well as IP addresses present in alternate tracking headers, such as the X-Forwarded-For header.
      2. Environment Manager–The environment manager parses the incoming user-agent header, if present.
      3. Session Manager–The session manager attempts to determine if the request contains the security engine tracking cookie in order to associate this request with an existing session. If this cookie is not present, the request will be fingerprinted later.
    4. Once these managers parse the request, the counter response service determines if any counter responses are active on this session and they are attached accordingly.
    5. Next, the processors are applied to the request, and incidents are triggered accordingly. For full information about each processor, consult the processor section that begins here Processors Overview.
    6. Next, a process runs to determine if the request was a URL fuzzing attempt, and incidents are triggered accordingly.
    7. Then, the request is made to the backend server itself.
    8. After the backend server returns a response, it passes through security engine again, where the processors are applied to the response, and incidents are triggered accordingly. For full information about each processor, consult the processor section that begins here Processors Overview.
    9. Finally, various headers are attached to the response, such as set-cookie (to set the WebApp Secure tracking cookie) and the response is returned to the client.

    Figure 1: HTTP Request/Response Flow

    HTTP Request/Response Flow

    Published: 2015-02-04