Process X-Forwarded-* headers

[jvllmr]

It would be great if granian could handle X-Forwarded headers for a smooth experience with reverse proxies without depending on a special setup or another dependency. Just declare your trusted proxies and you're good to go.

Here is how uvicorn handles these headers with its middleware which is baked into uvicorn: https://github.com/encode/uvicorn/blob/47304d9ae76321f0f5f649ff4f73e09b17085933/uvicorn/middleware/proxy_headers.py#L19

[gi0baro]

As discussed in #384, Granian won't strip any of those headers from the request, you should be able to see them.

Can you specify wether you'd like to have a control feature to strip those headers if not allowed or to have Granian update the ASGI scope based on forwarded headers? (or both?)

In the meantime, since Uvicorn uses a middleware, you can copy that code and wrap your application into that middleware to have 1:1 functionality implemented.

[jvllmr]

I'd firstly like to have a feature that updates the scope of the application similar to the middleware in uvicorn. I also think omitting these headers if they are not allowed could also be useful as it prevents spoofing attacks on logic that lives in the deployed application and uses the headers.

Furthermore, I want to list a few benefits from having this feature built-in that came to my mind just now:

• Having a standard implementation that multiple projects rely on means there is a probably secure implementation that is regularly audited. People who use that implementation don't risk implementing an insecure implementation themselves
• One could use another dependency besides Granian to have it implemented, but in i.e. the case of uvicorn I would install a whole asgi server and use an implementation that is bound to uvicorn's internals. In general I think it is always better to have less dependencies in a project.
• What if I want to host an ASGI application from soneone else that doesn't handle these headers because the developer forgot it or doesn't know about the headers in the first place? In that case I could try to contribute, but can be cumbersome. Especially if the project is rather small and the only maintainer is slow to respond. In that case a feature in Granian could avoid additional time and effort on pull requests to the original code base or wrappers around the application.
• Granian's access log feature currently logs before passing the request to the deployed app, doesn't it? The access log could also benefit here