You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While query strings are almost out of scope of the HTTP spec, in practice they are of course completely ubiquitous. While it's possible to encode them in the current API, it's certainly not possible to do it with any type safety or ease as the path component of a Request is just an untyped ByteString.
This is particularly hairy when trying to process a request just prior to sending, such as to append cryptographic signature information.
URIs have a lot more structure than that according to rfc3986, so it'd be nice to expose that structure more easily in the interface to http-common.
I propose adding more structured ways to query and build paths used in building Requests. This could be done by building atop existing URI packages like network, http-types, or uri. It also might be worth considering a fresh implementation if none of those packages provide an API which fits "nicely" into http-common's methods.
In particular, network is very old, uri and network both use String types, and http-types brings along more types, like Method, already replicated in http-common.
The text was updated successfully, but these errors were encountered:
At the moment http-streams depends on network (which we'd need anyway) but is where we get the Network.URI code to parse URLs in order to extract e.g. port numbers in the convenience methods. So if there's something there that does what you need then that would be useful to know.
While query strings are almost out of scope of the HTTP spec, in practice they are of course completely ubiquitous. While it's possible to encode them in the current API, it's certainly not possible to do it with any type safety or ease as the
path
component of aRequest
is just an untypedByteString
.This is particularly hairy when trying to process a request just prior to sending, such as to append cryptographic signature information.
URIs have a lot more structure than that according to rfc3986, so it'd be nice to expose that structure more easily in the interface to
http-common
.I propose adding more structured ways to query and build paths used in building
Request
s. This could be done by building atop existing URI packages likenetwork
,http-types
, oruri
. It also might be worth considering a fresh implementation if none of those packages provide an API which fits "nicely" intohttp-common
's methods.In particular,
network
is very old,uri
andnetwork
both useString
types, andhttp-types
brings along more types, likeMethod
, already replicated inhttp-common
.The text was updated successfully, but these errors were encountered: