public static final class HttpServer.Request

True when the request PATH is exactly these bytes.

The path, not the target: everything from ? onwards is the query string and is not part of the route. A router that compared the whole target would match /healthz and miss /healthz?probe=1, which is the same request.

For the generated router, which holds each route as a byte[] constant. No String is built and nothing is hashed: it is a length test and a compare against the buffer the request was parsed from. Falls back to comparing the target String when the slice is not available, which is the HTTP/2 path – there the target came from HPACK rather than from a byte range.

The path from from onwards, as text. Allocates, so a matched route only.

Percent escapes are left alone. The router decodes the segments it binds, because decoding first would let an encoded / invent a segment boundary that the client never sent.

A Response for this request WITHOUT allocating one.

Returns the connection’s single Response, re-pointed to these values. It is valid for the duration of Handler.handle and not beyond it – the same contract this Request already carries, and for the same reason: the next request on this connection reuses it.

Why it exists: on a route that allocates nothing else, the Response was the last per-request allocation, and allocation is what drives both the collector’s frequency and its footprint. Removing it measured a 15x better p99 and an 8x smaller resident set at the same throughput.

new Response(...) still works and still allocates; a handler that needs its Response to outlive the call must use it.

A JSON response on the connection’s pooled Response, serialised straight from the value.

The deferred-JSON path already avoided every copy on the body side – Json.write goes into the connection’s reusable ByteSink, so nothing materialises a byte[] or a String – but Response.jsonValue is a static that allocates a fresh Response per call, and that was the ONLY thing the route allocated. Profiled over 10.8M requests: 88.1 bytes each, all of it one HttpServer.Response, count 10789601 against 10789541 requests. The plaintext route had already been pooled and sat at 0.1 bytes per request.

That is worth removing because of what allocation costs HERE rather than what it costs to allocate: the collector shares the server’s cores, so a route that allocates pays for cycles in its tail. fasthttp on the same body allocates about 16 bytes per request and collects three times a second; this route was collecting thirteen to eighteen times a second.

reset() clears deferredJson and hasDeferredJson, so a pooled Response reused for a plain body cannot carry a stale value into the next response – which is the failure this would otherwise invite.

The address of the client this request is from.

That is the other end of the connection, unless this server was told it sits behind proxies and the connection is one of theirs. Then it is what X-Forwarded-For says, read from the right past every trusted proxy. From any other connection the header is ignored: it is the client’s own claim about itself.

IPv4 is dotted, IPv6 is eight groups of hexadecimal without ::, and an IPv4 address carried in IPv6 is written as IPv4 – one spelling per address, so the text can be a key.

The headers as a Map, lower-cased names to values.

Built on the first call and cached. Prefer getHeader: this allocates a String per name and per value, which is the cost the slice representation exists to avoid.

The body as text, or null when the request has none.

A text body – any Content-Type that is not binary, or none – was checked to be UTF-8 when it arrived, and a request whose body was not is answered 400 before any handler runs. A binary body (an upload, a multipart/form-data form) is meant for getBodyBytes. Asked for as text anyway, it is decoded when its bytes are UTF-8 – as Spring’s string converter reads any media type into a @RequestBody String – and throws when they are not, rather than handing a handler characters the client never sent.