KurocoEdge system architecture

KurocoEdge is a middleware, or proxy, processing the network traffic which passes through it between the user's browser and the origin server.

Requests & Responses

The following diagram outlines the request & response flow.

The user request reaches KurocoEdge, get processed by the request rules specified within KurocoEdge, then the processed request gets sent to the origin server - or redirected other backend domain based on the rule setup. The origin server returns a response, which reaches KurocoEdge, get processed by the response rules speicified within KurocoEdge, then the processed response is sent to the user.

Deployment

Within KurocoEdge, a deployment is an ordered set of rules, with each consisting of a collection of actions that are to be applied to the traffic on the KurocoEdge network. Deployments are versioned and only one version of a deployment can be active at the same time. You can, however, have as many draft versions as needed - and several people may work on different rule sets, each on their own version, using preview mode to test the rules will not affect any other draft versions, nor the active version that end users are currently using when browsing the site.

Rules

A rule defines a list of actions to be performed on requests and/or responses. The actions within a rule are processed from top to bottom order as displayed on the KurocoEdge admin panel
For each request, KurocoEdge will internally build two ordered lists of actions from all the applicable rules : a list of actions to be applied to the request, and another list of actions to be applied to the response. Rules are applicable when they match the conditions/expressions specified in the general configuration of the rule, such as URL Path Pattern or URL Path Prefix.

These two lists of request and response actions are almost independent, however they share few elements such as accessing the same unique data storage : if variables are captured in the request actions, the captured variables will also be available to use in the subsequent request and response actions. Therefore, allowing a rule to define both request and response actions within itself allows for compact and organized business logic that could specify the process from request to response.

Actions

Each action consists of 3 parts :

• Conditions/Variables : Here you define a list of conditions or variable definitions. Each condition results in true or false, and only if all condition items of an action are true, then the execution block will be processed. Additionnally, this is where you can define variables in multiple ways : statically (Static Variables), dynamically from an external API (Dynamic Variables), or capture using a regular expression from any part of the request/reponse such as headers, url, etc.
• Execution : This is where you define what should happen if all the conditions pass, if any. You may change request/response headers, define a new backend, respond with a Synthetic Response, create HTML editor rules, and much more.
• Directive flag : This is where you can find some optional configuration for the given action

Note that request and response actions have different settings. For example, HTML edit is only possible on the Response, while checking the client's IP address is only possible on the Request.

The following diagram describes the flow of request and response through KurocoEdge and its rules.

The request actions of all rules will be executed first, then followed by the response actions of all rules.

Additionally, each action can have its own condition. If the action's condition is fulfilled, then the action would be executed. If a rule has a request action with unfulfilled condition, then the request action will not be executed, however, the response action would still be executed if the response action's condition has been fulfilled.

In normal circumstances, the actions would be executed in the order of A → B → C → X → Y → Z, executing all the request actions (A,B,C) in order, then followed by response actions (X,Y,Z) when the response arrives from the origin.
However, if an action has the directive flag of Skip other actions during runtime enabled, then all subsequent action of the same type will be skipped.
For example, if request action B2 is executed with the flag Skip other actions during runtime enabled, then all subsequent request action (B3, C1, C2, C3) will not be executed. This flag, however, does not affect the response actions, therefore, all response action (X, Y, Z) will be executed.

Related documentations

• About KurocoEdge
• Rule execution priority