Classes

The following classes are available globally.

  • A ChannelInboundHandler used to decode HTTP requests. See the documentation on HTTPDecoder for more.

    While the HTTPRequestDecoder does not currently have a specific ordering requirement in the ChannelPipeline (unlike HTTPResponseDecoder), it is possible that it will develop one. For that reason, applications should try to ensure that the HTTPRequestDecoder later in the ChannelPipeline than the HTTPResponseEncoder.

    Rather than set this up manually, consider using ChannelPipeline.addHTTPServerHandlers.

    See more

    Declaration

    Swift

    public final class HTTPRequestDecoder : HTTPDecoder<HTTPServerRequestPart>
  • A ChannelInboundHandler used to decode HTTP responses. See the documentation on HTTPDecoder for more.

    The HTTPResponseDecoder must be placed later in the channel pipeline than the HTTPRequestEncoder, as it needs to see the outbound messages in order to keep track of what the HTTP request methods were for accurate decoding.

    Rather than set this up manually, consider using ChannelPipeline.addHTTPClientHandlers.

    See more

    Declaration

    Swift

    public final class HTTPResponseDecoder : HTTPDecoder<HTTPClientResponsePart>, ChannelOutboundHandler
  • A ChannelInboundHandler that parses HTTP/1-style messages, converting them from unstructured bytes to a sequence of HTTP messages.

    The HTTPDecoder is a generic channel handler which can produce messages in either the form of HTTPClientResponsePart or HTTPServerRequestPart: that is, it produces messages that correspond to the semantic units of HTTP produced by the remote peer.

    See more

    Declaration

    Swift

    public class HTTPDecoder<HTTPMessageT> : ByteToMessageDecoder, AnyHTTPDecoder
  • A ChannelOutboundHandler that can serialize HTTP requests.

    This channel handler is used to translate messages from a series of HTTPClientRequestPart into the HTTP/1.1 wire format.

    See more

    Declaration

    Swift

    public final class HTTPRequestEncoder : ChannelOutboundHandler
  • A ChannelOutboundHandler that can serialize HTTP responses.

    This channel handler is used to translate messages from a series of HTTPServerResponsePart into the HTTP/1.1 wire format.

    See more

    Declaration

    Swift

    public final class HTTPResponseEncoder : ChannelOutboundHandler
  • A HTTPResponseCompressor is a duplex channel handler that handles automatic streaming compression of HTTP responses. It respects the client’s Accept-Encoding preferences, including q-values if present, and ensures that clients are served the compression algorithm that works best for them.

    This compressor supports gzip and deflate. It works best if many writes are made between flushes.

    Note that this compressor performs the compression on the event loop thread. This means that compressing some resources, particularly those that do not benefit from compression or that could have been compressed ahead-of-time instead of dynamically, could be a waste of CPU time and latency for relatively minimal benefit. This channel handler should be present in the pipeline only for dynamically-generated and highly-compressible content, which will see the biggest benefits from streaming compression.

    See more

    Declaration

    Swift

    public final class HTTPResponseCompressor : ChannelDuplexHandler
  • A ChannelHandler that handles HTTP pipelining by buffering inbound data until a response has been sent.

    This handler ensures that HTTP server pipelines only process one request at a time. This is the safest way for pipelining-unaware code to operate, as it ensures that mutation of any shared server state is not parallelised, and that responses are always sent for each request in turn. In almost all cases this is the behaviour that a pipeline will want. This is achieved without doing too much buffering by preventing the Channel from reading from the socket until a complete response is processed, ensuring that a malicious client is not capable of overwhelming a server by shoving an enormous amount of data down the Channel while a server is processing a slow response.

    See RFC 7320 Section 6.3.2 for more details on safely handling HTTP pipelining.

    In addition to handling the request buffering, this ChannelHandler is aware of TCP half-close. While there are very few HTTP clients that are capable of TCP half-close, clients that are not HTTP specific (e.g. netcat) may trigger a TCP half-close. Having this ChannelHandler be aware of TCP half-close makes it easier to build HTTP servers that are resilient to this kind of behaviour.

    The TCP half-close handling is done by buffering the half-close notification along with the HTTP request parts. The half-close notification will be delivered in order with the rest of the reads. If the half-close occurs either before a request is received or during a request body upload, it will be delivered immediately. If a half-close is received immediately after HTTPServerRequestPart.end, it will also be passed along immediately, allowing this signal to be seen by the HTTP server as early as possible.

    See more

    Declaration

    Swift

    public final class HTTPServerPipelineHandler : ChannelDuplexHandler
  • A simple channel handler that catches errors emitted by parsing HTTP requests and sends 400 Bad Request responses.

    This channel handler provides the basic behaviour that the majority of simple HTTP servers want. This handler does not suppress the parser errors: it allows them to continue to pass through the pipeline so that other handlers (e.g. logging ones) can deal with the error.

    See more

    Declaration

    Swift

    public final class HTTPServerProtocolErrorHandler : ChannelDuplexHandler
  • A server-side channel handler that receives HTTP requests and optionally performs a HTTP-upgrade. Removes itself from the channel pipeline after the first inbound request on the connection, regardless of whether the upgrade succeeded or not.

    This handler behaves a bit differently from its Netty counterpart because it does not allow upgrade on any request but the first on a connection. This is primarily to handle clients that pipeline: it’s sufficiently difficult to ensure that the upgrade happens at a safe time while dealing with pipelined requests that we choose to punt on it entirely and not allow it. As it happens this is mostly fine: the odds of someone needing to upgrade midway through the lifetime of a connection are very low.

    See more

    Declaration

    Swift

    public class HTTPServerUpgradeHandler : ChannelInboundHandler