Classes

The following classes are available globally.

  • 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 final class HTTPDecoder<In, Out> : ByteToMessageDecoder, HTTPDecoderDelegate
    extension HTTPDecoder: WriteObservingByteToMessageDecoder where In == HTTPClientResponsePart, Out == HTTPClientRequestPart
  • 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, RemovableChannelHandler
  • 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, RemovableChannelHandler
  • 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, RemovableChannelHandler
  • 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, RemovableChannelHandler
  • 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 final class HTTPServerUpgradeHandler : ChannelInboundHandler, RemovableChannelHandler
  • A client-side channel handler that sends a HTTP upgrade handshake request to perform a HTTP-upgrade. When the first HTTP request is sent, this handler will add all appropriate headers to perform an upgrade to the a protocol. It may add headers for a set of protocols in preference order. If the upgrade fails (i.e. response is not 101 Switching Protocols), this handler simply removes itself from the pipeline. If the upgrade is successful, it upgrades the pipeline to the new protocol.

    The request sends an order of preference to request which protocol it would like to use for the upgrade. It will only upgrade to the protocol that is returned first in the list and does not currently have the capability to upgrade to multiple simultaneous layered protocols.

    See more

    Declaration

    Swift

    public final class NIOHTTPClientUpgradeHandler : ChannelDuplexHandler, RemovableChannelHandler
  • A ChannelInboundHandler that handles HTTP chunked HTTPServerRequestPart messages by aggregating individual message chunks into a single NIOHTTPServerRequestFull.

    This is achieved by buffering the contents of all received HTTPServerRequestPart messages until HTTPServerRequestPart.end is received, then assembling the full message and firing a channel read upstream with it. It is useful for when you do not want to deal with chunked messages and just want to receive everything at once, and are happy with the additional memory used and delay handling of the message until everything has been received.

    NIOHTTPServerRequestAggregator may end up sending a HTTPResponseHead:

    • Response status 413 Request Entity Too Large when either the content-length or the bytes received so far exceed maxContentLength.

    NIOHTTPServerRequestAggregator may close the connection if it is impossible to recover:

    • If content-length is too large and keep-alive is off.
    • If the bytes received exceed maxContentLength and the client didn’t signal content-length
    See more

    Declaration

    Swift

    public final class NIOHTTPServerRequestAggregator : ChannelInboundHandler, RemovableChannelHandler
  • A ChannelInboundHandler that handles HTTP chunked HTTPClientResponsePart messages by aggregating individual message chunks into a single NIOHTTPClientResponseFull.

    This is achieved by buffering the contents of all received HTTPClientResponsePart messages until HTTPClientResponsePart.end is received, then assembling the full message and firing a channel read upstream with it. Useful when you do not want to deal with chunked messages and just want to receive everything at once, and are happy with the additional memory used and delay handling of the message until everything has been received.

    If NIOHTTPClientResponseAggregator encounters a message larger than maxContentLength, it discards the aggregated contents until the next HTTPClientResponsePart.end and signals that via fireUserInboundEventTriggered.

    See more

    Declaration

    Swift

    public final class NIOHTTPClientResponseAggregator : ChannelInboundHandler, RemovableChannelHandler