Page MenuHomePhabricator

WIP RFC: Per-request middleware / request filters
Closed, ResolvedPublic

Description

We have some use cases that fit the request handler middleware / filter pattern:

  • title normalization and access checks
  • authentication
  • debug handlers
  • version checks / generic re-render handling for old content

Here is a sketch of how this *might* look:

x-request-filters:
  # - request / response handlers
  # - access to the entry point spec
  #   - security
  #   - URI template for redirects? Would need to figure out a relative
  #     redirect URL.
  #     - req.uri.expand with different params + convert to relative?
  # request(hyper, req, next)
  #   - manipulate request: return next(req')
  #   - manipulate response: next(req).then(...)
  #   - optionally, abort request (return response)
  - path: sys/normalize_title

x-request-handler:
  - from_storage:
     ....

Event Timeline

GWicke raised the priority of this task from to Medium.
GWicke updated the task description. (Show Details)
GWicke added a project: HyperSwitch.
GWicke added a subscriber: GWicke.
GWicke edited subscribers, added: mobrovac, Pchelolo, Eevans; removed: Aklapper.

@Pchelolo & I discussed this in the office. Some notes from that conversation:

  • Middleware handlers should be collected during lookup, similar to the way security restrictions are collected right now. This way, we can define general handlers high in the hierarchy, and have them apply to nested entry points.
  • Several use cases (validation, rewrites) can benefit from a separation between setup and handler execution, as the setup can be somewhat expensive. To support this, we can require each module to export a *factory* function, which then returns a closure with the actual handler. The factory can be passed a reference to the entry point path, along with explicit options defined for the handler.
  • For authentication, we have a need to conditionally forward headers to internal services *if* access is restricted. It might be possible to implement this by letting the middleware modify the hyper object per-request.

The title normalization use case could benefit from T127144: Create a MediaWiki title normalization library wrapped in a request handler middleware.

GWicke renamed this task from WIP RFC: Per-request middleware to WIP RFC: Per-request middleware / request filters.Feb 17 2016, 5:48 PM
GWicke updated the task description. (Show Details)
GWicke updated the task description. (Show Details)

While considering use cases, we noticed that we'll probably need two kinds of filters:

Route filters

These are accumulated during tree traversal in the router, and are then applied in-order to that specific request. They do have access to the handler spec. Use cases:

  • Access restrictions
  • Title normalization / revision and page restrictions
  • Per-entrypoint metrics
  • Swagger docs

Request or protocol filters

These are applied globally to all requests, including sub-requests, *before* routing. This means that they can rewrite requests before routing occurs. They can also intercept external requests, which shouldn't be routed at all.

On the flip side, these handlers don't have access to a spec, as this won't be resolved at this point.

Use cases:

  • Web requests (https?://)
  • HEAD handling
  • compression
  • CSP headers

A first iteration has been merged into master today. Likely next steps:

  • Per-entrypoint ("x-route-filter") filter registration.
  • Possibly, tackle title normalization as a filter.
  • Global handler registration, both for x-request and x-subrequest filters.
Pchelolo claimed this task.

Hm, this was implemented long time ago and is already actively used. Don't know why the task is still open, must have fell of our radar. Closing.