HeaderMapExt should provide a `typed_{try_}get` alternative that handles missing headers

[RReverser]

See the discussion in tokio-rs/axum#1781 (comment) for the original issue & motivation.

TL;DR is that Header::decode allows each typed header to handle empty iterators in its own way and let the header implementation decide whether missing header is an error or whether to provide some default "parsed" value (e.g. empty collection), but HeaderMapExt::typed_{try_}get always return Option::None when header is not found in the HeaderMap, not giving such Header implementation a chance to correctly provide their own fallback.

It would be useful to have variation of those methods that always return Result<H, Error> by forwarding an empty iterator to the specific H::decode implementation and letting it decide whether to provide a Ok(fallback_value) or emit an error.

[seanmonstar]

Ah, interesting. I guess a question then to answer is, are these two things worth distinguishing: the header was never sent, versus it was sent with an empty value.

[RReverser]

are these two things worth distinguishing: the header was never sent, versus it was sent with an empty value

I'd say it's really up to specific header implementation and/or consumer. I guess if you want to keep typed_try_get around alongside the new method, then consumers who want to check its existence, will be still able to do so, while others would probably not care and prefer to just get whatever spec dictates via the new method.

Alternatively, it could be useful to make Error an enum and then have a single method with Result<H, Error> signature. Then consumer will always easily get a header value where it's valid to do so, but will be able to distinguish between "header didn't exist" and "header was invalid" by looking at the error component if they want more granularity.

[RReverser]

Alternatively, it could be useful to make Error an enum and then have a single method with Result<H, Error> signature. Then consumer will always easily get a header value where it's valid to do so, but will be able to distinguish between "header didn't exist" and "header was invalid" by looking at the error component if they want more granularity.

No, wait, I'm too tired by now, that doesn't help / doesn't make any sense.