Response Validation in Proberix

Response validation lets you define specific patterns that a probe response must contain, exclude, or match exactly. This adds an extra layer of control by ensuring not just availability, but also content correctness or protocol compliance.

Response validation is supported in the following probe types:

• HTTP(S): Check for expected text in a web response.
• TCP: Validate banners, protocol replies, or custom payload responses.
• UDP: Match binary responses from services like DNS or custom protocols.
• DNS: Verify resolved records against expected results.

Why Validation Matters

Each probe type benefits from validation in unique ways:

• HTTP(S): Ensures the server is returning the expected HTML, API payload, or error page.
• TCP: Confirms that services are not only reachable but returning the right banner or protocol handshake.
• UDP: Allows matching binary or structured responses from stateless services (e.g. DNS, syslog).
• DNS: Detects incorrect resolution due to propagation issues or DNS hijacking.

Response Encoding (TCP and UDP only)

TCP and UDP responses can be binary or structured in a protocol-specific way. To support accurate validation, you can specify a Response Encoding for both the response body and the validation patterns.

Supported encodings:

• Plain Text: Treats response and patterns as UTF-8 text
• Hex: Interprets validation patterns as hexadecimal byte sequences
• Base64: Encodes patterns and responses in base64 for binary-safe matching

This flexibility ensures that non-text responses—common in TCP and UDP services—can be validated reliably.

Note: HTTP(S) and DNS responses are always treated as plain text and do not support response encoding options.

Validation Process

The validation process follows a consistent logic across all probes that support it:

1. Patterns are decoded using the specified Response Encoding (TCP/UDP only).
2. Each pattern is compared against the response body using the chosen Match Type:
   • Contains: Response must include the pattern
   • Not Contains: Response must not include the pattern
   • Exact: Response must exactly match the pattern
   • Regex: Response must match the regular expression
3. The Match All option determines whether all patterns must match or if any one is sufficient.
4. If no patterns are configured, validation automatically passes.

Example Behaviors

• Match Type: Contains, Match All: YES
  → All patterns must be found somewhere in the response.

• Match Type: Regex, Match All: NO
  → Response must match at least one of the provided regular expressions.

• Match Type: Exact
  → Useful when a static response (e.g., TCP banner or expected record) must match completely.

• Match Type: Not Contains
  → Ensures that no unwanted content or strings appear in the response.

When Validation Fails

If the response does not match the configured patterns according to the selected match type and logic, the probe result will be marked as:

• mismatch — Service is reachable, but the content is incorrect or unexpected.

This helps catch subtle issues like misconfigurations, version changes, hijacked services, or broken behavior behind otherwise healthy endpoints.

Best Practices

• Use Contains for partial matches like keywords, tokens, or banners.
• Use Exact sparingly—only when the entire response is deterministic.
• Use Regex for flexible pattern matching, especially for structured responses.
• Use Not Contains to detect blocked phrases or injected content.
• Choose the correct encoding when validating raw protocol responses in TCP/UDP probes.
• Avoid over-validating unless the content is known and stable—this can reduce false positives from benign changes.