Access to remote addr and httpversion about rocket HOT 7 CLOSED

What's the use case for knowing the HTTP version? I'll look into making the remote_addr available.

from rocket.

I believe in keeping the API as clean and simple as possible. If there's something that's unused 99% of the time with little reason to use it the rest, I don't believe that feature should be included. That may or may not be the case with exposing the HTTP version - I've personally never had a need for it. Still, I'll tag this "feedback wanted"; perhaps someone else has a good reason to have it exposed.

from rocket.

Well, I agree that HTTP version may not appear immediately useful. However, in general hiding this kind of information gives you little, while exposing as much as possible will definitely give your users things to experiment with.

from rocket.

Remote address is definitely useful. Many types of apps want to record the remote IP address for audit logs.

It’s also quite plausible that you might want to implement things differently in HTTP/1.1 and HTTP/2.0, e.g. bundle things up for HTTP/1.1 or use server push of more smaller resources in HTTP/2.0.

from rocket.

I have no qualms about exposing the remote address. I'm looking for use cases on exposing the HTTP version. I'm not sure returning different responses depending on the HTTP version is something I want Rocket to encourage or allow.

from rocket.

Since no one has chimed in about a reason to expose the HTTP version, it will not be exposed.

from rocket.

e.g. bundle things up for HTTP/1.1 or use server push of more smaller resources in HTTP/2.0.

Why wouldn't you want to encourage this? Is there a better way to deal with bundled/unbundled resources in Rocket already?

from rocket.