Core Behavior Changes

  1. Headers will no longer be split unnecessarily at the boundaries of Repose. If you were counting on this behavior, or for a list of headers that were being split, see Pre 9.0 Header Splitting.

  2. Headers with an empty value will no longer be automatically removed from requests or responses. If you were counting on this behavior, the Scripting Filter can be used. The scripting filter configuration may look like the following:

    <?xml version="1.0" encoding="UTF-8"?>
    <scripting xmlns="http://docs.openrepose.org/repose/scripting/v1.0"
             language="groovy">
      request.headerNames.each { headerName ->
          if (!request.getHeader(headerName)) {
              request.removeHeader(headerName)
          }
      }
      filterChain.doFilter(request, response)
      response.headerNames.each { headerName ->
          if (!response.getHeader(headerName)) {
              response.removeHeader(headerName)
          }
      }
    </scripting>
  3. The response status line reason phrase from the origin service will now be forwarded from the origin service. If you need Repose to normalize the reason phrase, see the Reason Phrase Normalization recipe.

  4. Requests can now contain headers with empty values. For example, if Repose receives a request with the header line `My-Header: `, that header line will now be forwarded to the origin service.

  5. Some core classes have been renamed. If you need to customize the logging behavior for the loggers used by these classes, or if you rely on these classes directly, use the following mapping to update to the new class names:

    Old Class Name New Class Name

    org.openrepose.powerfilter.PowerFilter

    org.openrepose.powerfilter.ReposeFilter

    org.openrepose.powerfilter.PowerFilterChain

    org.openrepose.powerfilter.ReposeFilterChain

  6. The Response Messaging Service has been removed. If you were counting on this behavior, the Scripting Filter can be used. The scripting filter configuration may look like the following:

    <?xml version="1.0" encoding="UTF-8"?>
    
    <scripting xmlns="http://docs.openrepose.org/repose/scripting/v1.0"
               language="groovy"><![CDATA[
        import groovy.xml.MarkupBuilder
    
        //Continue the filter chain
        filterChain.doFilter(request, response)
    
        //Check to see if we should monkey with the response because we have xml and a 2xx
        if((response.contentType ==~ /.*(xml|XML).*/) && (response.status >= 400) && (response.status < 600)) {
    
            //Uncommit the response just in case
            response.uncommit()
    
            //Clear the current response body
            response.resetBuffer()
    
            //Write the new body
            def xml = new MarkupBuilder(response.getWriter())
            xml.error() {
                status(response.getStatus())
                message(response.getReason())
            }
        }
    ]]></scripting>
  7. The Filter Chain now determines whether or not a filter should run based on the current state of the request rather than the state of the request when it was initially received. If you are applying a condition to filter activation (e.g., using the uri-regex attribute) and you modify some part of the request (e.g., the URL) in one of your filters, you may be impacted by this change. For more details, see filter activation determination.

System Model Configuration

  1. Support for multi-cluster deployments has been removed.

    1. The cluster element was removed from the system model. Remember that a cluster is just a logical grouping of nodes by their functionality, and as such, logical clusters can still be constructed outside of Repose.

      1. Repose clusters are no longer supported. Instead, an operator will need to define Repose behavior per-node. In other words, each Repose cluster will become a new system model configuration. To route a request between Repose nodes, see the following bullet.

      2. Service clusters (via round-robin routing) are no longer supported. Instead, an operator may choose to use a router to route traffic between destinations with identical functionality. A route could be anything from a physical F5 Load Balancer to a Cloud Load Balancer to an OpenShift service.

Container Configuration

  1. The via attribute was removed from the container configuration. It has been replaced with the via-header element. To replicate the previous behavior set the value that was previously in the via attribute in the request-prefix and response-prefix attributes of the new element.

  2. The soLingerTime attribute was removed from the container configuration. The underlying Jetty server no longer respects this value and therefore Repose will no longer expose it. To replicate the previous behavior you need to configure it in the operating system.

Deployment

  1. Support for installing Repose into an existing container has been dropped. For help moving to another deployment see Valve Installation and Quick Start with Docker.

  2. The package for valve installation has changed from repose-valve to repose.

  3. The Scripting Filter has been moved from the repose-experimental-filter-bundle to the repose-filter-bundle.

HTTP Client/Connection Pool Service

  1. If setting the chunked-encoding attribute, it will no longer be set in HTTP Client Service configuration but instead will be set in the System Model configuration.

    1. Deprecated configuration values have been removed; change 0 to false and 1 to true.

  2. The http.connection.max-status-line-garbage configuration attribute has been removed from the schema, and thus must be removed from configuration instances if present. This attribute has never affected the processing performed by Repose, and so it should be safe to remove in all cases.

Rackspace Auth User, SAML Policy Translation, and Attribute Mapping Policy Validation Filters

  1. Consult with identity for where these filters now live.

Header Normalization Filter

  1. All matching targets will now be processed, previously only the first target that matched would be evaluated.

URL Extractor to Header Filter

  1. All capture groups in the URL regex will now add their captured values to the desired header.

    1. If you have configured a URL regex with multiple capture groups but do not desire the values of some of those groups to be added to the header, use the non-capturing group construct (i.e., (?:X)). See the special constructs portion of the Java Pattern documentation for more information.

OpenStack Identity v3 Filter

  1. Removed deprecated caching attributes:

    1. token-cache-timeout on the openstack-identity-v3 element; token on the timeouts element should be used instead.

    2. groups-cache-timeout on the openstack-identity-v3 element; group on the timeouts element should be used instead.

    3. cache-offset on the openstack-identity-v3 element; variance on the timeouts element should be used instead.

  2. Cache timeouts are now defined in seconds rather than milliseconds.

    1. To convert existing timeouts, divide by 1000.

Keystone v2 and Keystone v2 Authorization Filters

  1. The uri-tenant-quality attribute was removed; the validated-tenant-quality should be used in its place.

  2. Support for extracting required tenant ID(s) from the URI was removed from the Keystone v2 Authorization Filter and Keystone v2 Filter configuration. To continue validating tenant ID(s) from the URI, follow these steps:

    1. Add the URL Extractor to Header Filter to your Filter Chain in the System Model.

    2. Configure the URL Extractor to Header Filter to extract tenant ID(s) to a new header.

      1. For example, if your Keystone v2 Authorization Filter or Keystone v2 Filter was configured with:

        <uri-extraction-regex>.*/servers/([:\-\w]+)/?.*</uri-extraction-regex>

        Then you would configure the URL Extractor to Header Filter with:

        <extraction url-regex=".*/servers/([:-\w]+)/?.*" header="X-Expected-Tenant"/>
    3. Replace usage of the uri-extraction-regex element with the header-extraction-name element in your Keystone v2 Authorization Filter and Keystone v2 Filter configuration.

      1. The value of the header-extraction-name element should match the value of the header name configured in the URL Extractor to Header Filter.

      2. Following the previous example, the configured header name would be X-Expected-Tenant. Therefore, the Keystone v2 Authorization Filter or Keystone v2 Filter configuration should contain:

        <header-extraction-name>X-Expected-Tenant</header-extraction-name>
    4. If desired, follow best practice guidelines by adding the configured header name to the Header Normalization Filter blacklist.

      1. Following the previous examples, the configured header name would be X-Expected-Tenant. Therefore, the Header Normalization Filter configuration should contain something like:

        <blacklist>
            <header id="X-Expected-Tenant"/>
        </blacklist>

For Integrators

Core

  1. The ServiceClient utility has been removed. The HTTP Client Service clients should be used instead.

  2. The HttpComponentFactory utility has been removed. Apache’s HTTP client RequestBuilder should be used instead.

HTTP Client/Connection Pool Service

  1. The following methods have been removed from the HTTP Client Service API and should no longer be used:

    1. releaseClient

    2. isAvailable

    3. getAvailableClients

    4. shutdown

Akka HTTP Client Service

  1. This service has been removed. Functionality has been migrated to the HTTP Client Service.

Request Proxy Service

  1. The following methods have been removed from the Request Proxy Service API and should no longer be used:

    1. setRewriteHostHeader

    2. proxyRequest(String, HttpServletRequest, HttpServletResponse, String)

Reporting Service

  1. This service has been removed. Functionality has been migrated to publish to the the Metrics Service.

  2. The incrementRequestCount an getTotalStatusCode methods can be retireved and manipulated using the following Meters and Timers:

    1. org.openrepose.core.ResponseCode.Repose.<statusCode>

    2. org.openrepose.core.ResponseCode.<location>.<statusCodeClass>

    3. org.openrepose.core.ResponseTime.Repose.<statusCode>

    4. org.openrepose.core.ResponseTime.<location>.<statusCodeClass>