[web-devel] Proposal: http-types

[Michael Snoyman]

On Wed, Feb 2, 2011 at 10:48 AM, Stefan Wehr <stefan.wehr at gmail.com> wrote:
> 2011/2/1 Michael Snoyman <michael at snoyman.com>:
>> On Tue, Feb 1, 2011 at 9:55 PM, Aristid Breitkreuz
>> <aristidb at googlemail.com> wrote:
>>> Hi,
>>> Hear me out, I have an idea! :-)
>>> How about creating a new package "http-types" containing Request / Response
>>> / status code / header name types for HTTP. These could be used by both
>>> server and client software, and might even allow switching between HTTP
>>> client libraries (say, if I want to switch between http-enumerator and
>>> HTTP).
>>> What do you think?
>>
>> I'm not opposed, I tried to already create all of those types in WAI.
>> Right now http-enumerator uses those types as well. If there are other
>> library writers who would agree to consolidate on such an http-types
>> package, I'll throw in these two packages as well.
>
> such a package would be helpful for us as well.
>
> -- Stefan
>

Let's speak practically here about what kind of types we're dealing with:

* Status, including the numeric code and status message. Eg, data
Status = Status Int ByteString
* Request/response header key. In WAI, I use data CIByteString =
CIByteString !ByteString !ByteString, one version being the lowercase,
the other the original.
* Request/response header value. In WAI, I use ByteString.
* Request and response datatypes themselves. I don't think this makes
sense to put in http-types: just between WAI and http-enumerator I
needed different versions of these.

In addition to this, I think it would be convenient to have a few
extra things besides types in this package:

* Status values like we have in WAI: status200/statusOK,
status404/statusNotFound, etc.
* A bunch of header keys: hdrContentType, hdrAccept, etc

Ideally, this package would only rely on base and bytestring.

Michael