Packages

  • package root
    Definition Classes
    root
  • package com
    Definition Classes
    root
  • package twitter

    Start with com.twitter.finagle.

    Definition Classes
    com
  • package finagle

    Finagle is an extensible RPC system.

    Finagle is an extensible RPC system.

    Services are represented by class com.twitter.finagle.Service. Clients make use of com.twitter.finagle.Service objects while servers implement them.

    Finagle contains a number of protocol implementations; each of these implement Client and/or com.twitter.finagle.Server. For example, Finagle's HTTP implementation, com.twitter.finagle.Http (in package finagle-http), exposes both.

    Thus a simple HTTP server is built like this:

    import com.twitter.finagle.{Http, Service}
    import com.twitter.finagle.http.{Request, Response}
    import com.twitter.util.{Await, Future}
    
    val service = new Service[Request, Response] {
      def apply(req: Request): Future[Response] =
        Future.value(Response())
    }
    val server = Http.server.serve(":8080", service)
    Await.ready(server)

    We first define a service to which requests are dispatched. In this case, the service returns immediately with a HTTP 200 OK response, and with no content.

    This service is then served via the Http protocol on TCP port 8080. Finally we wait for the server to stop serving.

    We can now query our web server:

    % curl -D - localhost:8080
    HTTP/1.1 200 OK

    Building an HTTP client is also simple. (Note that type annotations are added for illustration.)

    import com.twitter.finagle.{Http, Service}
    import com.twitter.finagle.http.{Request, Response}
    import com.twitter.util.{Future, Return, Throw}
    
    val client: Service[Request, Response] = Http.client.newService("localhost:8080")
    val f: Future[Response] = client(Request()).respond {
      case Return(rep) =>
        printf("Got HTTP response %s\n", rep)
      case Throw(exc) =>
        printf("Got error %s\n", exc)
    }

    Http.client.newService("localhost:8080") constructs a new com.twitter.finagle.Service instance connected to localhost TCP port 8080. We then issue a HTTP/1.1 GET request to URI "/". The service returns a com.twitter.util.Future representing the result of the operation. We listen to this future, printing an appropriate message when the response arrives.

    The Finagle homepage contains useful documentation and resources for using Finagle.

    Definition Classes
    twitter
  • package addr
    Definition Classes
    finagle
  • package builder
    Definition Classes
    finagle
  • package client
    Definition Classes
    finagle
  • package context
    Definition Classes
    finagle
  • package core
    Definition Classes
    finagle
  • package dispatch
    Definition Classes
    finagle
  • package exp

    Package exp contains experimental code.

    Package exp contains experimental code. This can be removed or stabilized (moved elsewhere) at any time.

    Definition Classes
    finagle
  • package factory
    Definition Classes
    finagle
  • package filter
    Definition Classes
    finagle
  • package http
    Definition Classes
    finagle
  • package codec
  • package collection
  • package cookie
  • package exp
  • package filter
  • package headers
  • package param
  • package path
  • package service
  • package util
  • AuthenticatedIdentityContext
  • Chunk
  • Cookie
  • CookieMap
  • CookieMapVersionSpecific
  • EmptyParamMap
  • Fields
  • FileElement
  • FormElement
  • HeaderMap
  • HeaderMapVersionSpecific
  • HttpMuxHandler
  • HttpMuxer
  • HttpMuxers
  • HttpTracing
  • InvalidUriException
  • KerberosAuthenticationFilter
  • LoadBalancedHostFilter
  • MapParamMap
  • MediaType
  • Message
  • Method
  • MethodBuilder
  • ParamMap
  • ParamMapVersionSpecific
  • ProxyCredentials
  • Request
  • RequestBuilder
  • RequestParamMap
  • RequestProxy
  • Response
  • ResponseProxy
  • Route
  • RouteIndex
  • SimpleElement
  • SpnegoAuthenticator
  • Status
  • TlsFilter
  • TooLongMessageException
  • Uri
  • Version
  • defaultClientProtocol
  • defaultServerProtocol
  • serverErrorsAsFailures
  • package http2
    Definition Classes
    finagle
  • package liveness
    Definition Classes
    finagle
  • package loadbalancer

    This package implements client side load balancing algorithms.

    This package implements client side load balancing algorithms.

    As an end-user, see the Balancers API to create instances which can be used to configure a Finagle client with various load balancing strategies.

    As an implementor, each algorithm gets its own subdirectory and is exposed via the Balancers object. Several convenient traits are provided which factor out common behavior and can be mixed in (i.e. Balancer, DistributorT, NodeT, and Updating).

    Definition Classes
    finagle
  • package logging
    Definition Classes
    finagle
  • package memcached
    Definition Classes
    finagle
  • package mux

    Package mux implements a generic RPC multiplexer with a rich protocol.

    Package mux implements a generic RPC multiplexer with a rich protocol. Mux is itself encoding independent, so it is meant to use as the transport for other RPC systems (eg. thrift). In OSI terminology, it is a pure session layer.

    In the below description, all numeric values are unsigned and in big-endian byte order. The schema size:4 body:10 defines the field size to be 4 bytes, followed by 10 bytes of the field body. The schema key~4 defines the field key to be defined by 4 bytes interpreted as the size of the field, followed by that many bytes comprising the field itself--it is shorthand for keysize:4 key:keysize. Groups are denoted by parenthesis; * denotes repetition of the previous schema 0 or more times, while {n} indicates repetition exactly n times. Unspecified sizes consume the rest of the frame: they may be specified only as the last field in the message.

    All strings in Mux are Utf-8 encoded, and are never null-terminated.

    Message framing

    Messages in mux are framed with a 4-byte big-endian size header, followed by 1 byte describing the message type and a 3-byte tag; or, diagrammatically: size:4 type:1 tag:3. The remainder of the frame (size-4 bytes) contains the body. Its format depends on the message type, documented below.

    Tag 0 designates a "marker" T message that expects no reply. Some messages may be split into an ordered sequence of fragments. Tag MSB=0 denotes the last message in such a sequence, making the tag namespace 23 bits. The tag is otherwise arbitrary, and is chosen by the sender of the T message.

    Currently, only Tdispatch and Rdispatch messages may be split into an ordered sequence of fragments. TdispatchError message ends a Tdispatch sequence and an Rerr ends an Rdispatch sequence.

    Message types, interpreted as a two's complement, 1-byte integer are numbered as follows: positive numbers are T-messages; their negative complement is the corresponding R message. T-messages greater than 63 (correspondingly R-messages smaller than -63) are session messages. The message number -128 is reserved for Rerr. All other messages are application messages. Middle boxes may forward application messages indiscriminately. Because of an early implementation bug, two aliases exist: 127 is Rerr, and -62 is Tdiscarded.

    The protocol is full duplex: both the server and client may send T messages initiating an exchange.

    Exchanges

    Messages are designated as "T messages" or "R messages", T and R being stand-ins for transmit and receive. A T message initiates an exchange and is assigned a free tag by the sender. A reply is either an R message of the same type (Rx replies to Tx for some x), or an Rerr, indicating a session layer error. R messages are matched to their T messages by tag, and the reply concludes the exchange and frees the tag for future use. Implementations should reuse small tag numbers.

    Messages

    size:4 Tinit:1 tag:3 version:2 (key~4 value~4)* reinitializes a session. Clients typically send this at the beginning of the session. When doing so, the sender may issue no more T messages until the corresponding size:4 Rinit:1 tag:3 version:2 (key~4 value~4)* has been received. After the Rinit was received, all connection state has been reset (outstanding tags are invalidated) and the stream is resumed according to the newly negotiated parameters. Prior to the first Tinit, the session operates at version 1. Rinit's version field is the accepted version of the session (which may be lower than the one requested by Tinit).

    size:4 Treq:1 tag:3 n:1 (key:1 value~1){n} body: initiates the request described by its body. The request body is delivered to the application. The request header contains a number of key-value pairs that describe request metadata.

    Keys for Treq messages are as follows:

    1. traceid: a 24-byte value describing the full Dapper trace id assigned by the client. The value's format is spanid:8 parentid:8 traceid:8.

    2. traceflag: a bitmask describing trace flags. Currently, the only defined flag is bit 0 which enables "debug mode", asking the server to force trace sampling.

    size:4 Tdispatch:1 tag:3 nctx:2 (ckey~2 cval~2){nc} dst~2 nd:2 (from~2 to~2){nd} body: implements destination dispatch. Tdispatch messages carry a set of keyed request contexts, followed by a logical destination encoded as a UTF-8 string. A delegation table follows describing rewrite rules that apply to this request.

    size:4 Rreq:1 tag:3 status:1 body: replies to a request. Status codes are as follows: 0=OK; the body contains the reply. 1=ERROR; the body contains a string describing the error. 2=NACK; a negative acknowledgment, the body contains a string describing the reason.

    size:4 Rdispatch:1 tag:3 status:1 nctx:2 (key~2 value~2){nctx} body: replies to a Tdispatch request. Status codes are as in Rreq. Replies can include request contexts. MuxFailure flags are currently sent via Rdispatch contexts under the "MuxFailure" key. See the MuxFailure flags section below.

    size:4 Rerr:1 tag:3 why: indicates that the corresponding T message produced an error. Rerr is specifically for server errors: the server failed to interpret or act on the message. The body carries a string describing the error.

    size:4 Tdrain:1 tag:3 is a request sent by the server telling the client to stop sending new requests. A client acknowledges this with an Rdrain message.

    size:4 Tping:1 tag:3 is sent by either party to check the liveness of its peer; these should be responded to immediately with a Rping message.

    size:4 Tdiscarded:1 tag:3 discard_tag:3 why: is a marker message and therefore has a tag value of 0. discard_tag indicates the tag of the Tdispatch to be discarded by the client. This can be used as a hint for early termination. Why is a string describing why the request was discarded. Note that it does *not* free the server from the obligation of replying to the original Treq.

    size:4 Tlease:1 tag:3 unit:1 howmuch:8 is a marker message indicating that a lease has been issued for howmuch units. As a marker message, its tag value must be 0. Unit '0' is reserved for duration in milliseconds. Whenever a lease has not been issued, a client can assume it holds an indefinite lease. Adhering to the lease is optional, but the server may reject requests or provide degraded service should the lease expire. This is used by servers to implement features like garbage collection avoidance.

    MuxFailure Flags

    Failure flags are read and written as an 8 byte integer. Unrecognized flags will be ignored silently, but should all be considered reserved for future use.

    Flag Value Meaning Restartable 1 << 0 Request is safe to re-issue Rejected 1 << 1 Request was rejected/Nacked by the server NonRetryable 1 << 2 Request should not be retried

    Security

    TLS is supported via three mechanisms: - Explicit and exclusive TLS. This pathway involves requiring the establishment of TLS immediately after establishing the socket connection. This is configured by adding TLS configuration to the client or server and not configuring opportunistic TLS or TLS snooping (see below).

    - Negotiated Opportunistic TLS. This pathway involves starting the connection as cleartext and the client and server subsequently negotiate a TLS level via the handshake. Based on that handshake the connection is either left as cleartext or upgraded to TLS. This is configured by adding TLS configuration and also configuring an opportunistic TLS level but not configuring TLS snooping.

    In this pathway there are three configuration options:

    • Off signals that TLS is not supported by this peer
    • Desired signals that TLS is preferred but not required by this peer
    • Required signals that this peer will only allow the session to continue over TLS

    - TLS snooping. This pathway allows a server to use TLS either by performing a TLS handshake immediately after the socket is established or by starting the session as cleartext or using the negotiated pathway described above. If the session is started as a TLS session the headers that drive the opportunistic TLS pathway are ignored.

    Note that the server may still require TLS but leaves the option to start TLS immediately after establishing the socket or starting cleartext and requiring TLS via the opportunistic TLS pathway described above.

    Definition Classes
    finagle
  • package mysql
    Definition Classes
    finagle
  • package namer
    Definition Classes
    finagle
  • package naming
    Definition Classes
    finagle
  • package netty4

    Package netty4 implements the bottom finagle primitives: com.twitter.finagle.Server and a client transport in terms of the netty4 event loop.

    Package netty4 implements the bottom finagle primitives: com.twitter.finagle.Server and a client transport in terms of the netty4 event loop.

    Definition Classes
    finagle
  • package offload
    Definition Classes
    finagle
  • package param

    Defines common com.twitter.finagle.Stack.Param's shared between finagle clients and servers.

    Defines common com.twitter.finagle.Stack.Param's shared between finagle clients and servers.

    Definition Classes
    finagle
  • package partitioning
    Definition Classes
    finagle
  • package pool
    Definition Classes
    finagle
  • package postgresql
    Definition Classes
    finagle
  • package pushsession
    Definition Classes
    finagle
  • package redis
    Definition Classes
    finagle
  • package scribe
    Definition Classes
    finagle
  • package server
    Definition Classes
    finagle
  • package serverset2
    Definition Classes
    finagle
  • package service
    Definition Classes
    finagle
  • package ssl
    Definition Classes
    finagle
  • package stats
    Definition Classes
    finagle
  • package thrift

    Please use the new interface, com.twitter.finagle.Thrift, for constructing Thrift clients and servers.

    Deprecation

    Please use the new interface, com.twitter.finagle.Thrift, for constructing Thrift clients and servers.

    Thrift codecs

    We provide client and server protocol support for the framed protocol. The public implementations are defined on the Thrift object:

    The type of the server codec is Service[Array[Byte], Array[Byte]] and the client codecs are Service[ThriftClientRequest, Array[Byte]]. The service provided is that of a "transport" of thrift messages (requests and replies) according to the protocol chosen. This is why the client codecs need to have access to a thrift ProtocolFactory.

    These transports are used by the services produced by the finagle thrift codegenerator.

    val service: Service[ThriftClientRequest, Array[Byte]] = ClientBuilder()
      .hosts("foobar.com:123")
      .stack(Thrift.client)
      .build()
    
    // Wrap the raw Thrift transport in a Client decorator. The client
    // provides a convenient procedural interface for accessing the Thrift
    // server.
    val client = new Hello.ServiceToClient(service, protocolFactory)

    In this example, Hello is the thrift interface, and the inner class ServiceToClient is provided by the finagle thrift code generator.

    Definition Classes
    finagle
  • package thriftmux
    Definition Classes
    finagle
  • package toggle
    Definition Classes
    finagle
  • package tracing
    Definition Classes
    finagle
  • package transport
    Definition Classes
    finagle
  • package tunable
    Definition Classes
    finagle
  • package util
    Definition Classes
    finagle
  • package zipkin
    Definition Classes
    finagle
  • package zookeeper
    Definition Classes
    finagle

package http

Linear Supertypes
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. http
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Package Members

  1. package codec
  2. package collection
  3. package cookie
  4. package exp
  5. package filter
  6. package headers
  7. package param
  8. package path
  9. package service
  10. package util

Type Members

  1. sealed abstract class Chunk extends AnyRef

    Represents a piece of an HTTP stream, commonly referred to as a chunk.

    Represents a piece of an HTTP stream, commonly referred to as a chunk.

    HTTP semantics treat trailing headers as the end of stream signal hence no writes (neither trailers nor data) are allowed after them, only close (EOS) is valid. This is typically enforced by an HTTP dispatcher in both clients and servers.

    Similarly, when consumed via com.twitter.io.Reader, trailers are always followed by None, readers's EOS. Users MUST read until the end of stream to ensure resource hygiene.

    The following example demonstrates one way of doing so: wiring in one extra read before returning from a read-loop:

    def accumulate(r: Reader[Chunk]): Future[(Buf, Option[HeaderMap])] = {
      def loop(acc: Buf, trailers: Option[HeaderMap]): Future[(Buf, Option[HeaderMap])] =
        r.read().flatMap {
          case Some(chunk) =>
            if (chunk.isLast && !chunk.trailers.isEmpty)
              loop(acc.concat(chunk.content), Some(chunk.trailers))
            else
              loop(acc.concat(chunk.content), None)
          case None =>
            Future.value(acc -> trailers)
        }
    
      loop(Buf.Empty, None)
    }

    The HTTP dispatcher guarantees that Chunk.Last will be issued in the inbound stream no matter if its trailers or content present.

    Note: when consuming interleaved HTTP streams (i.e., via Reader.flatMap) it's expected to observe multiple trailers before reaching the EOS. These inter-stream trailers space out individual HTTP streams from child readers.

  2. final class Cookie extends AnyRef

    Note

    domain and path may be null.

  3. class CookieMap extends CookieMapVersionSpecific

    Adapt cookies of a Message to a mutable Map where cookies are indexed by their name.

    Adapt cookies of a Message to a mutable Map where cookies are indexed by their name. Requests use the Cookie header and Responses use the Set-Cookie header. If a cookie is added to the CookieMap, a header is automatically added to the Message. You can add the same cookie more than once. Use getAll to retrieve all of them, otherwise only the first one is returned. If a cookie is removed from the CookieMap, a header is automatically removed from the message

  4. abstract class CookieMapVersionSpecific extends Map[String, Cookie]
    Attributes
    protected
  5. final case class FileElement(name: String, content: Buf, contentType: Option[String] = None, filename: Option[String] = None) extends FormElement with Product with Serializable
  6. sealed abstract class FormElement extends AnyRef
  7. abstract class HeaderMap extends HeaderMapVersionSpecific with Map[String, String]

    Mutable message headers map.

    Mutable message headers map.

    Header names are case-insensitive. For example, get("accept") is the same as get("Accept").

    The map is a multi-map. Use getAll to get all values for a key. Use add to append a key-value.

  8. abstract class HeaderMapVersionSpecific extends AnyRef
    Attributes
    protected
  9. trait HttpMuxHandler extends Service[Request, Response]

    Trait HttpMuxHandler is used for service-loading HTTP handlers.

  10. class HttpMuxer extends Service[Request, Response]

    A service that dispatches incoming requests to registered handlers.

    A service that dispatches incoming requests to registered handlers. In order to choose which handler to dispatch the request to, we take the path of the request and match it with the patterns of the pre-registered handlers. The pattern matching follows these rules:

    • Patterns ending with "/" use exclusive prefix matching. Eg: the pattern "foo/bar/" matches these paths: "foo/bar/", "foo/bar/baz", etc but NOT "foo/bar" Similarly, the pattern "/" matches all paths
    • Patterns not ending with "/" use exact matching. Eg: the pattern "foo/bar" ONLY matches this path: "foo/bar"
    • Special case: The pattern "" matches only "/" and ""

    NOTE: When multiple pattern matches exist, the longest pattern wins.

  11. final class InvalidUriException extends ChannelException with FailureFlags[InvalidUriException] with HasLogLevel
  12. class MapParamMap extends ParamMap

    Map-backed ParamMap.

  13. abstract class Message extends AnyRef

    Rich Message

    Rich Message

    Base class for Request and Response. There are both input and output methods, though only one set of methods should be used.

  14. final class Method extends AnyRef

    Represents the HTTP method.

    Represents the HTTP method.

    The method is a case-sensitive string defined as part of the request line of the HTTP protocol.

    See also

    https://tools.ietf.org/html/rfc7230#section-3.1.1

  15. class MethodBuilder extends BaseMethodBuilder[MethodBuilder]

    MethodBuilder is a collection of APIs for client configuration at a higher level than the Finagle 6 APIs while improving upon the deprecated ClientBuilder.

    MethodBuilder is a collection of APIs for client configuration at a higher level than the Finagle 6 APIs while improving upon the deprecated ClientBuilder. MethodBuilder provides:

    • Logical success rate metrics.
    • Retries based on application-level requests and responses (e.g. an HTTP 503 response code).
    • Configuration of per-attempt and total timeouts.

    All of these can be customized per method (or endpoint) while sharing a single underlying Finagle client. Concretely, a single service might offer both GET statuses/show/:id as well as POST statuses/update, whilst each having wildly different characteristics. The GET is idempotent and has a tight latency distribution while the POST is not idempotent and has a wide latency distribution. If users want different configurations, without MethodBuilder they must create separate Finagle clients for each grouping. While long-lived clients in Finagle are not expensive, they are not free. They create duplicate metrics and waste heap, file descriptors, and CPU.

    Example

    A client that has timeouts and retries on a 418 status code.

    import com.twitter.conversions.DurationOps._
    import com.twitter.finagle.Http
    import com.twitter.finagle.service.{ReqRep, ResponseClass}
    import com.twitter.util.Return
    
    val client: Http.Client = ???
    client.methodBuilder("inet!example.com:80")
      .withTimeoutPerRequest(50.milliseconds)
      .withTimeoutTotal(100.milliseconds)
      .withRetryForClassifier {
        case ReqRep(_, Return(rep)) if rep.statusCode == 418 => ResponseClass.RetryableFailure
      }
      .newService("an_endpoint_name")

    Timeouts

    Defaults to using the StackClient's configuration.

    An example of setting a per-request timeout of 50 milliseconds and a total timeout of 100 milliseconds:

    import com.twitter.conversions.DurationOps._
    import com.twitter.finagle.Http
    import com.twitter.finagle.http.MethodBuilder
    
    val builder: MethodBuilder = ???
    builder
      .withTimeoutPerRequest(50.milliseconds)
      .withTimeoutTotal(100.milliseconds)

    Retries

    Retries are intended to help clients improve success rate by trying failed requests additional times. Care must be taken by developers to only retry when it is known to be safe to issue the request multiple times. This is because the client cannot always be sure what the backend service has done. An example of a request that is safe to retry would be a read-only request.

    Defaults to using the client's ResponseClassifier to retry failures marked as retryable. See withRetryForClassifier for details.

    A com.twitter.finagle.service.RetryBudget is used to prevent retries from overwhelming the backend service. The budget is shared across clients created from an initial MethodBuilder. As such, even if the retry rules deem the request retryable, it may not be retried if there is insufficient budget.

    Finagle will automatically retry failures that are known to be safe to retry via com.twitter.finagle.service.RequeueFilter. This includes WriteExceptions and retryable nacks. As these should have already been retried, we avoid retrying them again by ignoring them at this layer.

    Additional information regarding retries can be found in the user guide.

    The classifier is also used to determine the logical success metrics of the method. Logical here means after any retries are run. For example should a request result in retryable failure on the first attempt, but succeed upon retry, this is exposed through metrics as a success. Logical success rate metrics are scoped to "clnt/your_client_label/method_name/logical" and get "success" and "requests" counters along with a "request_latency_ms" stat.

    Unsuccessful requests are logged at com.twitter.logging.Level.DEBUG level. Further details, including the request and response, are available at TRACE level.

    See also

    com.twitter.finagle.Http.Client.methodBuilder to construct instances.

    The user guide.

  16. abstract class ParamMap extends ParamMapVersionSpecific

    Request parameter map.

    Request parameter map.

    This is a persistent (immutable) multi-map.

    Use getAll() to get all values for a key.

  17. abstract class ParamMapVersionSpecific extends Map[String, String]
    Attributes
    protected
  18. case class ProxyCredentials(username: String, password: String) extends Product with Serializable
  19. abstract class Request extends Message

    Rich HttpRequest.

    Rich HttpRequest.

    Use RequestProxy to create an even richer subclass.

  20. class RequestBuilder[HasUrl, HasForm] extends AnyRef
  21. class RequestParamMap extends ParamMap

    Http Request-backed ParamMap.

    Http Request-backed ParamMap. This ParamMap contains both parameters provided as part of the request URI and parameters provided as part of the request body.

    Note

    Request body parameters are considered if the following criteria are true:

    1. The request is not a TRACE request. 2. The request media type is 'application/x-www-form-urlencoded' 3. The content length is greater than 0.
  22. abstract class RequestProxy extends Proxy

    Proxy for Request.

    Proxy for Request. This can be used to create a richer request class.

  23. abstract class Response extends Message

    Rich HttpResponse

  24. abstract class ResponseProxy extends Proxy

    Proxy for Response.

    Proxy for Response. This can be used to create a richer response class.

  25. case class Route(pattern: String, handler: Service[Request, Response], index: Option[RouteIndex] = None) extends Product with Serializable

    Represents an element which can be routed to via the HttpMuxer.

    Represents an element which can be routed to via the HttpMuxer.

    pattern

    The pattern the handler is bound to. This is also often used as the path to access the route, but if something more detailed is required, the RouteIndex.path parameter can be used.

    handler

    The service which requests are routed to.

    index

    Optionally contains information for the route UI.

  26. case class RouteIndex(alias: String, group: String, path: Option[String] = None, method: Method = Get) extends Product with Serializable

    Contains the route UI information.

    Contains the route UI information.

    alias

    A short name used to identify the route when listed in index.

    group

    A grouping used to organize the route in the index. Routes with the same grouping are displayed together.

    path

    The path used to access the route. A request is routed to the path as per the com.twitter.finagle.http.HttpMuxer spec. The path only needs to be specified if the URL accessed in the admin interface is different from the pattern provided in Route.pattern.

    method

    Specifies which HTTP Method to use from com.twitter.finagle.http.Method. The default is Method.Get. Only Method.Get and Method.Post are supported.

  27. final case class SimpleElement(name: String, content: String) extends FormElement with Product with Serializable
  28. case class Status(code: Int) extends Product with Serializable

    Represents an HTTP status code.

    Represents an HTTP status code.

    The set of commonly known HTTP status codes have an associated reason phrase (see reasons). We don't provide a way to set the reason phrase because:

    - it simplifies construction (users only supply the code) - it avoids the need to validate user-defined reason phrases - it omits the possibility of statuses with duplicate reason phrases

    The only downside is that we lose the ability to create custom statuses with "vanity" reason phrases, but this should be tolerable.

  29. class TlsFilter extends SimpleFilter[Request, Response]

    Adds the host headers to for TLS-enabled requests.

  30. final class TooLongMessageException extends ChannelException with FailureFlags[TooLongMessageException]

    The Message was too long to be handled correctly

  31. final class Uri extends AnyRef

    Represents an immutable URI.

  32. final case class Version extends Product with Serializable

    Represents the HTTP version.

Value Members

  1. object AuthenticatedIdentityContext
  2. object Chunk
  3. object Cookie
  4. object EmptyParamMap extends ParamMap

    Empty ParamMap

  5. object Fields
  6. object HeaderMap
  7. object HttpMuxer extends HttpMuxer

    Singleton default multiplex service.

    Singleton default multiplex service.

    See also

    HttpMuxers for Java compatibility APIs.

  8. object HttpMuxers

    Java compatibility APIs for HttpMuxer.

  9. object HttpTracing
  10. object KerberosAuthenticationFilter

    Apply kerberos authentication to http requests.

  11. object LoadBalancedHostFilter

    Adds host header to load balanced requests.

    Adds host header to load balanced requests.

    Example:
    1. Overriding the TlsFilter host header setting with this module:

      import com.twitter.finagle.Http
      import com.twitter.finagle.loadbalancer.LoadBalancerFactory
      Http.client.withStack(Http.client.stack.remove(TlsFilter.role)
        .insertAfter(LoadBalancerFactory.role, LoadBalancedHostFilter.module))
    Note

    If Transporter.EndpointAddr was not created via java.net.InetSocketAddress.createUnresolved, the filter will make an asynchronous network call to determine the hostname.

    ,

    Since this stack module expects a Transporter.EndpointAddr to be set, it only makes sense to configure it below a module that sets the Transporter.EndpointAddr (typically via com.twitter.finagle.loadbalancer.LoadBalancerFactory).

    See also

    com.twitter.finagle.loadbalancer.LoadBalancerFactory for details on how Transporter.EndpointAddr is selected

  12. object MapParamMap
  13. object MediaType
  14. object Message
  15. object Method
  16. object MethodBuilder
  17. object ParamMap
  18. object ProxyCredentials extends Serializable
  19. object Request
  20. object RequestBuilder

    Factory for com.twitter.finagle.http.RequestBuilder instances

  21. object Response
  22. object SpnegoAuthenticator

    A SPNEGO HTTP authenticator as defined in https://tools.ietf.org/html/rfc4559, which gets its credentials from a provided CredentialSource...

    A SPNEGO HTTP authenticator as defined in https://tools.ietf.org/html/rfc4559, which gets its credentials from a provided CredentialSource... usually JAAS.

  23. object Status extends Serializable
  24. object TlsFilter
  25. object TooLongMessageException extends Serializable
  26. object Uri
  27. object Version extends Serializable
  28. object defaultClientProtocol extends GlobalFlag[Protocol]

    GlobalFlag that can be used to configure the default protocol used when creating a new com.twitter.finagle.Http.Client.

  29. object defaultServerProtocol extends GlobalFlag[Protocol]

    GlobalFlag that can be used to configure the default protocol used when creating a new com.twitter.finagle.Http.Server.

  30. object serverErrorsAsFailures extends GlobalFlag[Boolean]

Inherited from AnyRef

Inherited from Any

Ungrouped