Filters and services

This page and its children relate to Repose filters and services. You can select and customize Repose filters and services to suit your application.

Standard filter order

The filters in Repose are compiled byte-codes that have configuration files that provide functionality between the client and the origin service. These filters often interact with each other, so the order in which you list them in the system model is important. You can use a filter to gather information from third-party servers that will then pass information to other filters. For example, you can use the Client Authentication filter to determine a user's role before it is used by the API Validation filter.

Although not all filters have strict dependencies, using the standard default order prevents you from injecting unnecessary bugs into your deployment.  Some deployments might require a different order from the standard order. Additionally, not all filters are required for each deployment. You define which filters and services are deployed within your system model.

Note: This table does not contain the full list of filters.

SLF4J HTTP LoggingPlace the Simple Logging Facade for Java (SLF4J) HTTP Logging filter at the top of the filter chain.
CORS FilterPlace the CORS filter near the top to handle Preflight Requests.
Forwarded ProtocolPlace the Forwarded Protocol filter near the top of your filter chain.
Add HeaderPlace this filter before any filters that need to receive the added static header in the request.
URL Extractor to HeaderPlace this filter before any filters that need to receive the added dynamic header in the request.

Header Normalization

Place the Normalization filters near the top. These filters clean the request to prevent unexpected request headers and content. 

URI Normalization
Header Translation
Place the Header Translation filter before filters that need headers translated.
Keystone v2 Basic AuthenticationPlace the Keystone v2 Basic Authentication filter before the authentication and authorization filters so that they can process the X-Auth-Token header.
Keystone v2Place the Keystone v2 filter before the other identity filters. This filter sets the X-Roles, X-PP-User, and X-PP-Groups headers.
OpenStack Identity v3Place the OpenStack Identity filter before the other identity filters. This filter sets the X-Roles, X-PP-User, and X-PP-Groups headers.
Client AuthenticationPlace the Client Authentication filter before the identity filters. This filter sets the X-Roles, X-PP-User, and X-PP-Groups headers.
Header UserPlace the user filters next. These filters provide alternative methods of setting the X-PP-User and X-PP-Groups headers.

IP User
URI User
Client AuthorizationPlace the Client Authorization filter next to validate whether the user has access to the requested endpoint. 
Rackspace Auth UserPlace the Rackspace Auth User filter before the Rate Limiting filter. This filter removes the username from the body and sets it in the X-PP-User header for rate limiting.
Highly Efficient Record Processor (HERP) Place the HERP filter after the authentication and authorization filters.
Delegation Response Processor (DeRP)Place the DeRP filter after the HERP filter.
Rate LimitingPlace the Rate Limiting filter next. This filter uses the URI, X-PP-User, and X-PP-Groups to establish rate limits. 
VersioningPlace the Versioning filter before the Validation filter to finalize the URI.
CompressionPlace the Compression filter before anything that looks at the request body. 
API (WADL/XSD) ValidationPlace the API (WADL/XSD) Validation filter after the Compression filter. API (WADL/XSD) Validation filter uses X-Roles to validate requests.
Simple RBACPlace the Simple RBAC filter after the Compression filter.
TranslationPlace these filters last in the filter chain. They do not need to precede any other filters.
Destination Router
URI Stripper
Content Type Stripper
Merge Header

You may use two instances of this filter.

  • Place it at the top of the filter chain if you plan use the filter for responses.
  • Place it at the bottom of the filter chain if you plan to use the the filter for requests.

Filter names, XSDs, examples, and descriptions

The following tables include the filter and service names that are used in the system model, the path to the XML schemas, and example configuration files. The filters and services are divided into categories that define their most basic function. Click the links for more detailed information about each component. 

Request-response modification filters

Rate limiting filter

Filter name<filter-name>XML schema definitionExample configurationDescription
Rate Limitingrate-limitingrate-limiting-configuration.xsdrate-limiting.cfg.xmlThis filter can be configured to manage the flow of traffic into your service, so that it does not exceed the service's actual capacity. 

Authentication filters

Other filters


Item<service-name>XML schema definitionExample configurationDescription
Analysismetricsmetrics.xsdmetrics.cfg.xmlThis service is available in Repose versions 2.8.1 and later.
Atom Feed Consumption Serviceatom-feed-serviceatom-feed-service.xsdatom-feed-service.cfg.xmlEnables simple reading of Atom feeds. By centralizing this function in a service, Repose developers may share resources (and reduce overhead) when multiple Repose components need to read the same feed.
Datastoresdist-datastoredist-datastore-configuration.xsddist-datastore.cfg.xmlRepose uses one of the datastore implementations to store various types of data. Current implementations are the Distributed Datastore Service and the Local Datastore.
Health Check service---Allows Repose to return 503 error messages on bad configurations or requests when using other Repose service components.
HTTP Connection Poolhttp-connection-pools--Allows Repose to manage and reuse HTTP connections.
Response Messaging Service response-messagingresponse-messaging.xsdresponse-messaging.cfg.xmlThe Response Messaging Service (RMS) allows Repose to intercept the response and return a pre-configured message body.

Deprecated filters