Skip to main content

pv1_1

pv1_1 = 1

Example​

procedure ConfigureHTTP(Client: TvxHTTP);
begin
  Client.ProtocolVersion := pv1_1;
  Client.Get('https://api.example.invalid/v1/status');
end;

Usage​

pv1_1 selects the default HTTP/1.1 request line and Velox's HTTP/1.1 method and connection-handling rules for Velox HTTP.

Scope and quirks

  • The value selects the outbound HTTP/1.1 request line. It does not require the server's response to use the same version.
  • It does not enable HTTP/2 or HTTP/3 and does not perform application-layer protocol negotiation.
  • It is unrelated to TLS protocol selection; an https request still depends on the configured SSL/TLS handler.
  • HTTP/1.1 framing, Host, connection and proxy headers are built by Velox from the request state. Setting the enum alone does not validate user-supplied header combinations.
  • Redirect, authentication, proxy routing, timeout, response and body behavior have separate controls.

Additional Technical Info​

pv1_1 selects the HTTP/1.1 branch of Indy's TIdHTTPProtocolVersion. When assigned to TvxHTTP.ProtocolVersion, the next request line ends in HTTP/1.1.

This is the explicit default for new TvxHTTP instances and Velox HTTP transports, as well as Indy's underlying default. It should remain selected unless an endpoint has a verified HTTP/1.0 compatibility requirement.

Method and POST behavior

Indy requires this value for the exposed TRACE, PUT, OPTIONS, DELETE and PATCH methods. If pv1_0 is selected, those method names are rejected before any request is sent. Selecting pv1_1 passes that version gate; it does not guarantee that the server authorises or implements the method.

POST also preserves pv1_1 in Velox. The compiled modified Indy file retains an old automatic HTTP/1.0 POST workaround only as commented code and explicitly states that it must not alter the user's selected protocol. Documentation or examples based on the upstream downgrade behavior do not describe this Velox build.

Connection handling

Indy's HTTP/1.1 branch assumes a connection can persist unless the request, response or applicable proxy response says Connection: close/Proxy-Connection: close, or the socket has already closed. This decision is keyed from the configured request version rather than the separately parsed response version.

Velox's TvxHTTP.SendRequest still calls Disconnect in finally after every request that reaches method dispatch, on success or error. Consequently, scripts gain HTTP/1.1 request semantics and method compatibility but do not gain connection reuse across separate TvxHTTP method calls. Redirects and authentication retries inside one request lifecycle can still use Indy's internal connection processing before that final disconnect.

Related entries

External references

Created 2026-07-15