openapi3filter: fix bug where absent optional properties fail validation in form-urlencoded requests

[thierry-f-78]

openapi3filter: fix bug where absent optional properties fail validation in form-urlencoded requests

Summary

Fix validation of absent optional properties in application/x-www-form-urlencoded request bodies.

The Bug

When a form-urlencoded request body has multiple optional properties defined in the schema, and only some of them are sent in the request, the validation incorrectly fails with:

Error at "/param2": Value is not nullable

Reproduction case:

• Schema defines two optional string properties: param1 and param2
• Request sends only param1=value1
• Expected: validation passes (param2 is optional)
• Actual: validation fails because absent param2 is treated as null

Note: the bug only manifests when at least one property is present. An empty body passes validation.

The Fix

When decoding properties, skip absent ones entirely instead of adding them as null to the decoded object:

value, present, err := decodeProperty(dec, name, prop, encFn)
if err != nil || !present {
    continue
}

Specification Analysis

Absent vs Null: Two Distinct Concepts

According to OpenAPI Specification discussions:

"Basically null has the meaning of 'this property existed before, and I want to nullify its value'. If there's no value, or the value needs not change, it just shouldn't be sent."

This clearly distinguishes:

• Absent: property not sent ‚Üí should not be validated
• Null: property explicitly set to null ‚Üí should be validated against nullable

No Native Null in form-urlencoded

RFC 1866 defines form-urlencoded as key=value pairs where:

• param=value ‚Üí string value
• param= ‚Üí empty string ""
• absence of param ‚Üí not sent

The RFC states: "Fields with null values may be omitted" ‚Äî but here "null" means "no value" in HTML form semantics, not the JSON null type.

There is no native way to represent JSON null in form-urlencoded.

Ambiguity: nullable in form-urlencoded

The OpenAPI 3.0.3 specification does not define how nullable: true should behave for form-urlencoded content. It only references RFC 1866 for serialization rules.

This means nullable is arguably meaningless for form-urlencoded bodies, since there's no standard way to send an explicit null value. This is a spec ambiguity, not something this PR attempts to resolve.

What This PR Does

• Fixes the immediate bug: absent optional properties no longer cause validation errors
• Adds a regression test for this case
• Does NOT change behavior for required validation or nullable semantics (separate concerns)