No client authentication is requested or required.

Accept authentication if presented by client. If this option is set and the client chooses not to provide authentication information about itself, the negotiations will continue.

Require client to present authentication, if not presented then negotiations will be declined.

Base WebSocket implementation.

It implements both and so it can be used with Pump to pump data with flow control.

Configures the engine to require/request client authentication.

Created by manishk on 10/2/2015.

A frame.

HTTP2 settings, the settings is initialized with the default HTTP/2 values.

The settings expose the parameters defined by the HTTP/2 specification, as well as extra settings for protocol extensions.

An asynchronous HTTP client.

It allows you to make requests to HTTP servers, and a single client can make requests to any server.

It also allows you to open WebSockets to servers.

The client can also pool HTTP connections.

For pooling to occur, keep-alive must be true on the HttpClientOptions (default is true). In this case connections will be pooled and re-used if there are pending HTTP requests waiting to get a connection, otherwise they will be closed.

This gives the benefits of keep alive when the client is loaded but means we don't keep connections hanging around unnecessarily when there would be no benefits anyway.

The client also supports pipe-lining of requests. Pipe-lining means another request is sent on the same connection before the response from the preceding one has returned. Pipe-lining is not appropriate for all requests.

To enable pipe-lining, it must be enabled on the HttpClientOptions (default is false).

When pipe-lining is enabled the connection will be automatically closed when all in-flight responses have returned and there are no outstanding pending requests to write.

The client is designed to be reused between requests.

Options describing how an HttpClient will make connections.

Represents a client-side HTTP request.

Instances are created by an HttpClient instance, via one of the methods corresponding to the specific HTTP methods, or the generic request methods. On creation the request will not have been written to the wire.

Once a request has been obtained, headers can be set on it, and data can be written to its body if required. Once you are ready to send the request, one of the end methods should be called.

Nothing is actually sent until the request has been internally assigned an HTTP connection.

The HttpClient instance will return an instance of this class immediately, even if there are no HTTP connections available in the pool. Any requests sent before a connection is assigned will be queued internally and actually sent when an HTTP connection becomes available from the pool.

The headers of the request are queued for writing either when the end method is called, or, when the first part of the body is written, whichever occurs first.

This class supports both chunked and non-chunked HTTP.

It implements WriteStream so it can be used with Pump to pump data with flow control.

An example of using this class is as follows:

Represents a client-side HTTP response.

Vert.x provides you with one of these via the handler that was provided when creating the HttpClientRequest or that was set on the HttpClientRequest instance.

It implements ReadStream so it can be used with Pump to pump data with flow control.

Represents an HTTP connection.

HTTP/1.x connection provides an limited implementation, the following methods are implemented:

• [close](../http/HttpConnection.type.html#close)
• [closeHandler](../http/HttpConnection.type.html#closeHandler)
• [exceptionHandler](../http/HttpConnection.type.html#exceptionHandler)

An HTTP/2 frame.

Represents an HTTP method

An HTTP and WebSockets server.

You receive HTTP requests by providing a requestHandler. As requests arrive on the server the handler will be called with the requests.

You receive WebSockets by providing a websocketHandler. As WebSocket connections arrive on the server, the WebSocket is passed to the handler.

Represents an file upload from an HTML FORM.

Represents options used by an HttpServer instance

Represents a server-side HTTP request.

Instances are created for each request and passed to the user via a handler.

Each instance of this class is associated with a corresponding HttpServerResponse instance via response.

It implements ReadStream so it can be used with Pump to pump data with flow control.

Represents a server-side HTTP response.

An instance of this is created and associated to every instance of HttpServerRequest that.

It allows the developer to control the HTTP response that is sent back to the client for a particular HTTP request.

It contains methods that allow HTTP headers and trailers to be set, and for a body to be written out to the response.

It also allows files to be streamed by the kernel directly from disk to the outgoing HTTP connection, bypassing user space altogether (where supported by the underlying operating system). This is a very efficient way of serving files from the server since buffers do not have to be read one by one from the file and written to the outgoing socket.

It implements WriteStream so it can be used with Pump to pump data with flow control.

Represents the version of the HTTP protocol.

Options describing how an HttpClient will make connect to make a request.

Represents a server side WebSocket.

Instances of this class are passed into a websocketHandler or provided when a WebSocket handshake is manually upgradeed.

Represents a client-side WebSocket.

A WebSocket frame that represents either text or binary data.

A WebSocket message is composed of one or more WebSocket frames.

If there is a just a single frame in the message then a single text or binary frame should be created with final = true.

If there are more than one frames in the message, then the first frame should be a text or binary frame with final = false, followed by one or more continuation frames. The last continuation frame should have final = true.

Represents the WebSocket version

No client authentication is requested or required.

Accept authentication if presented by client. If this option is set and the client chooses not to provide authentication information about itself, the negotiations will continue.

Require client to present authentication, if not presented then negotiations will be declined.