Summary
Per RFC THV-0017's failure modes table, HTTP 422 from a webhook should always deny the request regardless of the configured failure policy (fail or ignore). Currently, both the validating and mutating webhook middleware treat all errors uniformly via the failure policy, meaning a 422 with ignore policy would fall back to the original body instead of denying.
This affects both middleware types:
pkg/webhook/validating/middleware.gopkg/webhook/mutating/middleware.go
Context
Identified during review of #4372 (Phase 3: Mutating webhook middleware). The InvalidResponseError in client.go already surfaces the status code, so the middleware just needs to check for 422 before applying the failure policy.
Expected behavior
When a webhook endpoint returns HTTP 422 (Unprocessable Entity), the middleware must deny the request unconditionally, regardless of whether the failure policy is set to fail or ignore.
Summary
Per RFC THV-0017's failure modes table, HTTP 422 from a webhook should always deny the request regardless of the configured failure policy (
failorignore). Currently, both the validating and mutating webhook middleware treat all errors uniformly via the failure policy, meaning a 422 withignorepolicy would fall back to the original body instead of denying.This affects both middleware types:
pkg/webhook/validating/middleware.gopkg/webhook/mutating/middleware.goContext
Identified during review of #4372 (Phase 3: Mutating webhook middleware). The
InvalidResponseErrorinclient.goalready surfaces the status code, so the middleware just needs to check for 422 before applying the failure policy.Expected behavior
When a webhook endpoint returns HTTP 422 (Unprocessable Entity), the middleware must deny the request unconditionally, regardless of whether the failure policy is set to
failorignore.