Currently, libraries that use http::Request have 2 different ways to represent a request, dependent on the expected usage (client or server). This seems confusing, and I'd like to discuss if this is something that needs to be changed.
Most notably: It seems that absolute URIs are used in client contexts. But it server contexts, relative URIs with Host header are used. I propose that instead, the type should have a canonical representation that is valid in any context.
(Ideally, the canonical representation should be the only representation that is buildable, but this is a separate discussion.)
Practically, I think that using relative URIs is best, because it allows HTTP/1.0 requests where the Host header was not required. However, this requires the addition of a "scheme" field because this is currently stored in the uri field in client contexts.
What are the thoughts about this and the potential changes that it would require?
Currently, libraries that use http::Request have 2 different ways to represent a request, dependent on the expected usage (client or server). This seems confusing, and I'd like to discuss if this is something that needs to be changed.
Most notably: It seems that absolute URIs are used in client contexts. But it server contexts, relative URIs with Host header are used. I propose that instead, the type should have a canonical representation that is valid in any context.
(Ideally, the canonical representation should be the only representation that is buildable, but this is a separate discussion.)
Practically, I think that using relative URIs is best, because it allows HTTP/1.0 requests where the Host header was not required. However, this requires the addition of a "scheme" field because this is currently stored in the uri field in client contexts.
What are the thoughts about this and the potential changes that it would require?