Package org.mockserver.matchers

Class HttpRequestPropertiesMatcher

java.lang.Object
org.mockserver.model.ObjectWithReflectiveEqualsHashCodeToString
org.mockserver.matchers.NotMatcher<RequestDefinition>
org.mockserver.matchers.AbstractHttpRequestMatcher
org.mockserver.matchers.HttpRequestPropertiesMatcher
All Implemented Interfaces:
HttpRequestMatcher, Matcher<RequestDefinition>
public class HttpRequestPropertiesMatcher extends AbstractHttpRequestMatcher
Matches HTTP request properties against expectation criteria.

Null/Blank Matcher Behavior: When a specific matcher (e.g., method, path, headers) is null or blank, it matches all values for that property. This allows expectations to match broadly without specifying every field. For example:

  • No method matcher → matches any HTTP method (GET, POST, etc.)
  • No path matcher → matches any request path
  • No header matcher → matches requests with any headers

This "filter" behavior improves UX: unspecified fields act as wildcards, so users can create simple expectations without boilerplate "match anything" patterns.

Concurrency: a single matcher instance is shared between the control plane (which rebuilds the compiled criterion in apply(RequestDefinition) when an expectation is created or updated — a single-writer path) and the data plane (which reads the compiled criterion in matches(org.mockserver.matchers.MatchDifference, org.mockserver.model.RequestDefinition) from many Netty event-loop threads concurrently). To stop a concurrent control-plane update from exposing a half-rebuilt matcher to an in-flight match, all per-criterion compiled state lives in an immutable HttpRequestPropertiesMatcher.Compiled holder built fully inside apply() and published through a single volatile reference (compiled). matches() snapshots that reference once on entry and reads everything from the snapshot, so it sees either the entire old criterion or the entire new one — never a torn mix.

Author:
jamesdbloom