Represents an HTTP Cookie.
All cookies must have a name and a value and can optionally have other fields set such as path, domain, etc.
(Derived from io.netty.handler.codec.http.Cookie)
A parsed language header.
Delivers a more direct access to the individual elements of the header it represents
A container with the request's headers that are meaningful enough to be parsed Contains: <ul> <li>Accept -> MIME header, parameters and sortable</li> <li>Accept-Charset -> Parameters and sortable</li> <li>Accept-Encoding -> Parameters and sortable</li> <li>Accept-Language -> Parameters and sortable</li> <li>Content-Type -> MIME header and parameters</li> </ul>
A route is a holder for a set of criteria which determine whether an HTTP request or failure should be routed to a handler.
A router receives request from an @see \io\vertx\jphp\core\http\HttpServer and routes it to the first matching
Represents the context for the handling of a request in Vert.x-Web.
A new instance is created for each HTTP request that is received in the of the router.
The same instance is passed to any matching request or failure handlers during the routing of the request or failure.
The context provides access to the and and allows you to maintain arbitrary data that lives for the lifetime of the context. Contexts are discarded once they have been routed to the handler for the request.
The context also provides access to the @see \io\vertx\jphp\ext\web\Session, cookies and body for the request, given the correct handlers in the application.
Represents a browser session.
Sessions persist between HTTP requests for a single browser session. They are deleted when the browser is closed, or they time-out. Session cookies are used to maintain sessions using a secure UUID.
Sessions can be used to maintain data for a browser session, e.g. a shopping basket.
The context must have first been routed to a @see \io\vertx\jphp\ext\web\handler\SessionHandler for sessions to be available.
Base interface for HTTP request validation with API specification
Main interface for Design Driven Router factory Author: Francesco Guardiani @slinkydeveloper
Interface for OpenAPI3RouterFactory. <br/> To add an handler, use @see \io\vertx\jphp\ext\web\api\contract\openapi3\OpenAPI3RouterFactory::addHandlerByOperationId<br/> Usage example: <pre> <code>OpenAPI3RouterFactory.create(vertx, "src/resources/spec.yaml", asyncResult -> { if (!asyncResult.succeeded()) { // IO failure or spec invalid</code> else { OpenAPI3RouterFactory routerFactory = asyncResult.result(); routerFactory.addHandlerByOperationId("operation_id", routingContext -> { // Do something }, routingContext -> { // Do something with failure handler }); Router router = routerFactory.getRouter(); } }); } </pre> <br/> Handlers are loaded in this order:<br/> <ol> <li>Body handler (Customizable with </li> <li>Custom global handlers configurable with </li> <li>Global security handlers defined in upper spec level</li> <li>Operation specific security handlers</li> <li>Generated validation handler</li> <li>User handlers or "Not implemented" handler</li> </ol>
This interface is used to add custom <b>synchronous</b> functions inside validation process. You can add it in
An interface for add HTTP Request validation. This class can validate parameters inside query, path, headers an body (watch below) <br/> You can assign multiple body type at the same time(for example a JSON schema together with a XML schema). This interface support: <ul> <li>application/x-www-form-urlencoded</li> <li>multipart/form-data</li> <li>application/xml</li> <li>application/json</li> </ul> Also you can add a form parameter for validation without care about content type of your request. For form parameters this interface support both "multipart/form-data" and "application/x-www-form-urlencoded" <br/> This interface allow extra parameters in the request, so it doesn't care if in a request there's a parameter without a specified validation rule <br/> If a parameter is flagged as an array, it will be validated also if the size of array is 1 element
Interface for declaration of method for validate a specific parameter type.<br/> If you want to implement your own type validator, you need only to implement
This function is an inner wrapper for ParameterTypeValidator inside ValidationHandler parameter maps. <b>Don't instantiate this class</b>, if you want to add custom ParameterTypeValidator to a parameter use functions in
Base interface for validation.
For basic HTTP Request Validator, use @see \io\vertx\jphp\ext\web\api\validation\HTTPRequestValidationHandler
An HTTP response.
The usual HTTP response attributes are available:
The body of the response is returned by @see \io\vertx\jphp\ext\web\client\HttpResponse::body decoded as the format specified by the @see \io\vertx\jphp\ext\web\codec\BodyCodec that built the response.
Keep in mind that using this HttpResponse impose to fully buffer the response body and should be used for payload
that can fit in memory.
An asynchronous HTTP / HTTP/2 client called <code>WebClient</code>.
The web client makes easy to do HTTP request/response interactions with a web server, and provides advanced features like:
The web client does not deprecate the , it is actually based on it and therefore inherits
its configuration and great features like pooling. The HttpClient should be used when fine grained control over the HTTP
requests/response is necessary.
Options describing how an @see \io\vertx\jphp\core\http\HttpClient will make connections.
Converts a @see \io\vertx\jphp\ext\web\client\predicate\ResponsePredicateResult to a <code>Throwable</code> describing the error.
A predicate on .
By default, a Vert.x Web Client request ends with an error only if something wrong happens at the network level.
In other words, a 404 Not Found response, or a response with the wrong content type, are NOT considered as failures.
Represents the outcome of a @see \io\vertx\jphp\ext\web\client\predicate\ResponsePredicate applied to an .
A template template uses a specific template and the data in a routing context to render a resource into a buffer.
Concrete implementations exist for several well-known template engines.
Base interface for auth handlers.
An auth handler allows your application to provide authentication/authorization support.
Auth handler requires a @see \io\vertx\jphp\ext\web\handler\SessionHandler to be on the routing chain before it.
A handler which gathers the entire request body and sets it on the .
It also handles HTTP file uploads and can be used to limit body sizes.
A handler which decodes cookies from the request, makes them available in the and writes them back in the response.
A handler which implements server side http://www.w3.org/TR/cors/[CORS] support for Vert.x-Web.
This handler adds a CSRF token to requests which mutate state. In order change the state a (XSRF-TOKEN) cookie is set with a unique token, that is expected to be sent back in a (X-XSRF-TOKEN) header.
The behavior is to check the request body header and cookie for validity.
This Handler requires session support, thus should be added somewhere below Session and Body handlers.
A handler that serves favicons.
If no file system path is specified it will attempt to serve a resource called `favicon.ico` from the classpath.
Handler that handles login from a form on a custom login page.
Used in conjunction with the @see \io\vertx\jphp\ext\web\handler\RedirectAuthHandler.
An auth handler that provides OAuth2 Authentication support. This handler is suitable for AuthCode flows.
An auth handler that's used to handle auth by redirecting user to a custom login page.
A handler which sets the response content type automatically according to the best <code>Accept</code> header match.
The header is set only if:
Handler which adds a header `x-response-time` in the response of matching requests containing the time taken in ms to process the request.
A handler that maintains a @see \io\vertx\jphp\ext\web\Session for each browser session.
It looks up the session for each request based on a session cookie which contains a session ID. It stores the session when the response is ended in the session store.
The session is available on the routing context with .
The session handler requires a @see \io\vertx\jphp\ext\web\handler\CookieHandler to be on the routing chain before it.
A handler which renders responses using a template engine and where the template name is selected from the URI path.
Handler that will timeout requests if the response has not been written after a certain time.
Timeout requests will be ended with an HTTP status code 503.
This handler should be used if you want to store the User object in the Session so it's available between different requests, without you having re-authenticate each time.
It requires that the session handler is already present on previous matching routes.
It requires an Auth provider so, if the user is deserialized from a clustered session it knows which Auth provider to associate the session with.
Represents an event that occurs on the event bus bridge.
Please consult the documentation for a full explanation.
A handler that allows you to handle SockJS connections from clients.
We currently support version 0.3.3 of the SockJS protocol, which can be found in this tag:
You interact with SockJS clients through instances of SockJS socket.
The API is very similar to @see \io\vertx\jphp\core\http\WebSocket. It implements both and so it can be used with
A session store which stores sessions in a distributed map so they are available across the cluster.
A session store which is only available on a single node.
Can be used when sticky sessions are being used.
A template engine uses a specific template and the data in a routing context to render a resource into a buffer.
Concrete implementations exist for several well-known template engines.