Skip to content

execution-flow.md

Latest commit

 

History

History
74 lines (51 loc) · 2.04 KB

execution-flow.md

File metadata and controls

74 lines (51 loc) · 2.04 KB

Execution Flow

liquidrazor/http-kernel currently proves one HTTP request/response path through the LiquidRazor runtime stack.

The implemented flow is:

native input
  -> request adapter
  -> HttpRequestInterface
  -> HttpTransportContext
  -> HttpExchangeInterface
  -> HTTP lifecycle events
  -> MicroKernel execution boundary
  -> request RuntimeContext / ScopeId
  -> configured HTTP handler
  -> HttpResponseInterface
  -> response finalizer
  -> HttpTransportOutput
  -> emitter boundary

Input Forms

The kernel currently accepts:

  • a normalized array handled by GenericHttpRequestAdapter
  • an existing HttpTransportInput carrying an HttpRequestInterface

The generic adapter does not read PHP globals or php://input.

Request Phase

During request preparation the kernel:

  • normalizes request method, URI, path, query, headers, cookies, body, uploaded files, and protocol version
  • classifies the request body into an upstream RequestBodyInterface
  • creates an HTTP exchange
  • dispatches request lifecycle events through EventManager

Execution Phase

The kernel submits HTTP work to MicroKernel using an executable work descriptor and a callback.

The handler runs behind that execution boundary with:

  • the current HttpExchangeInterface
  • a child-side RuntimeContext

For successful execution, the boundary returns a response-bearing exchange.

For handler failures, the boundary can return a mapped HttpTransportOutput produced by the failure mapper.

Response Phase

The response finalizer:

  • validates that the exchange contains a response
  • emits HttpResponsePreparedEvent
  • creates HttpTransportOutput when one does not already exist
  • preserves an existing transport status when one was already mapped
  • emits HttpResponseFinalizedEvent

The emitter boundary then hands the finalized output to the configured emitter.

Current Scope

The implemented path is intentionally narrow:

  • one configured handler
  • no router
  • no controller resolution
  • no middleware discovery
  • no bridge-specific runtime integration