Remove Host and Scheme extractors from axum-extra

[jplatte]

This is a counter-proposal to #2998: let's just remove these extractors. If people can agree on a useful version of them, they can maintain their own library for them.

Reasons:

• they seem very niche to me (have never used either of them)
• it's not at all obvious what exactly they do
• as such, people seem to expect different things
• we were thinking about introducing new concepts into axum(-extra) just for these two (or are there more "spoofable" extractors?)

Thoughts? @mladedav @Turbo87 @yanns @GlenDC @tottoto (maybe we need a GH team 😅)

[tottoto]

I feel it seems reasonable to remove them.

[mladedav]

Yeah, I think we can delete them for now and see the fallout.

[ZylosLumen]

I would like to suggest to please not remove Host, it is very useful for routing subdomains inside a single server. "use nginx" is not an alternative as some might make it seem

[mladedav]

Is TypedHeader<Host> not enough for your use case?

[GlenDC]

In https://github.com/plabayo/rama/ we have the authority for that in the "RequestContext".

Not sure about @ZylosLumen's use case, but if I understand him correctly it is not enough to just rely
on the Host header. Sometimes that header is not there, and sometimes you want instead to use forward
information from one of the forward headers or via something like HaProxy (L4~)....

[ZylosLumen]

Is TypedHeader<Host> not enough for your use case?

I did not know about that. From testing it seems I can preserve the same behaviour by using Option and .hostname(). Good to know 👍

Not sure about @ZylosLumen's use case, but if I understand him correctly it is not enough to just rely
on the Host header. Sometimes that header is not there, and sometimes you want instead to use forward
information from one of the forward headers or via something like HaProxy (L4~)....

I actually did not know that the Host extractor has multiple sources. I thought it existed to allow getting the Host header without consuming the headers in a middleware via HeaderMap. For my current use case I do not care about handling non-browser(-like) or indirect requests so I just fallback to responding with the homepage (/)

Now that I think about it, it could be beneficial to remove it so that people are forced to correctly understand where the data is sourced from. I suppose #2998 is the alternative -- keeping the extractors but nudging people towards investigating/reading the docs while still allowing low level control using the primitives the extractors are built upon. I should have done so myself first 😅