Zod cannot validate headers

[ClayMav]

Description

When using zod for validation, the headers (type Headers) are being safeParse'd into an object and that doesn't work, so if a route required headers, it just can't be validated.

Reproducible example or configuration

No response

OpenAPI specification (optional)

No response

System information (optional)

No response

[dosubot]

Hi @ClayMav! I'm Dosu and I’m helping the openapi-ts team.

This is a known limitation: Zod can't validate the Headers object directly because it's not a plain JavaScript object, and Zod schemas expect plain objects as input. In the current hey-api/openapi-ts setup, generated Zod schemas for requests set headers as z.never().optional(), meaning headers aren't validated or are explicitly disallowed in the schema (docs).

If you need to validate headers, you'll need to manually convert the Headers object to a plain object before passing it to Zod. There isn't a built-in utility for this in the project right now. The Zod plugin is still in beta, so this may change in future releases (plugin docs).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[mrlubos]

@ClayMav Is this for requests or responses? Can you share a StackBlitz example?

[vinayraghu1]

Ran into this last week. I think the generated client's beforeRequest hook runs mergeHeaders(), which converts plain header objects into Web API Headers instances. From this point on, any property should be accessed with a .get instead of bracket notation like headers["Authorization"]. Happy to open a PR if you point me to the right file

[mrlubos]

@vinayraghu1 Do you have a spec to reproduce?

[vinayraghu1]

I tried fixing in #3449 but looks like tests are failing and also it is no exhaustive as some plugin code might live elsewhere.

[vinayraghu1]

This issue has a spec to repro

[spietras]

Keep in mind that if you convert Headers to an object, you will get lowercase keys (I assume because headers are normally case insensitive, so they normalise it like that). But the ones in the Zod schema might have different casing if you have different casing in your OpenAPI specification (and it's a rather common convention to specify headers which are not lowercase), as it seems to be mapped 1:1 as far as I can tell. So in such cases, you will end up with an error anyway, because keys in objects are case sensitive. Possibly the schema creation process needs to transform keys in schemas to lowercase, too.