Download the PHP package velt/http without Composer
On this page you can find all versions of the php package velt/http. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package http
Velt HTTP
velt/http is the web transport layer for Velt applications. It provides requests, responses, JSON responses, routing, controller dispatch, middleware pipelines, response normalization, sessions and CSRF foundations while relying on velt/kernel for application services.
Status: alpha. Routing and dispatch are functional; production hardening for proxies, uploads, streaming, rate limiting and security policy remains tracked in the repository milestone.
Installation
Requirements: PHP 8.2+ and velt/kernel.
Register the HTTP layer
The service provider connects HTTP services to the application container without moving HTTP behavior into the kernel.
Define routes
Routes support parameter matching and route-specific middleware. A route under /api is treated as an API route by the current response normalization logic.
Request API
Requests normalize method, path, query/input collections and headers. Application validation must still enforce domain rules and reject unexpected values.
Responses
ResponseInterface exposes status, headers, body and send behavior. ResponseFactory converts controller results and exceptions into consistent web or API responses. Controllers can return response objects, renderable values, JSON-compatible values or supported primitives.
Controller dispatch
The dispatcher matches the route, resolves controller instances through the container, passes route parameters and sends the result through the response factory.
Middleware
Pipeline executes middleware in declared order and terminates at the route handler. Middleware should return a response and avoid hidden global state.
The dispatcher can handle CORS preflight requests. Origins are denied by default and must be configured explicitly:
An allowed OPTIONS request returns 204 with explicit Access-Control-Allow-* headers. Wildcard origins are not added automatically when credentials are enabled.
Sessions and CSRF
SessionStoreInterface supports get, set, has and remove. PhpSessionStore adapts PHP sessions. CsrfTokenManager creates, renders and validates CSRF tokens:
Production applications must configure secure cookie attributes, HTTPS, session rotation and storage appropriate for their deployment. PhpSessionStore::configureSecureDefaults() enables Secure, HttpOnly and SameSite=Lax defaults. CSRF protects state-changing browser requests; API authentication requires a separate policy.
Error behavior
HttpException carries an HTTP status code. The response factory distinguishes API and web error formats. In production, diagnostics must never disclose stack traces, source paths, request secrets or database credentials.
Recommended API envelope:
Front controller example
Current production checklist
The current hardening layer provides:
- explicit CORS origins and preflight responses;
- trusted host and forwarded-host validation;
- request method, URI, header and body-size validation;
- secure session cookie defaults and session rotation;
- in-memory rate limiting for a process.
Before Velt HTTP is considered stable, the project is completing:
- trusted proxy and host validation;
- CORS policy and preflight handling;
- upload and stream contracts;
- request/body/header size limits;
- secure cookie/session defaults and identifier rotation;
- rate limiting and resource protection;
- content-negotiated error rendering;
- malformed input, CRLF, traversal and fuzz tests;
- concurrency and long-running runtime state isolation.
The native Android bridge does not use HTTP internally. HTTP remains a web and development-preview adapter, not a substitute for JNI.
Testing
The suite covers request accessors, responses, routing, dispatch, middleware pipeline and CSRF behavior. New features must include success and failure cases plus security-focused regression tests.
Contributing
Keep transport behavior in this repository and application/domain behavior outside it. Public changes require updated examples, stable error contracts and compatibility evidence with the kernel and skeleton.
License
MIT
