[Haskell-cafe] How to use http-enumerator with hoauth?

Michael Snoyman michael at snoyman.com
Wed Feb 16 05:02:21 CET 2011


On Wed, Feb 16, 2011 at 2:05 AM, Jeremy Fitzhardinge <jeremy at goop.org> wrote:
> On 02/15/2011 02:14 PM, Vincent Hanquez wrote:
>> Clearly, http-enumerator is the best package for doing http/https. however
>> since it's pretty new, lots of package still uses their own abstraction for
>> doing things.
>>
>> While it may be possible to retrofit hoauth to use http-enumerator, using the
>> httpclient typeclass, that's going to be hard to fit the full enumerator
>> interface on it, so you won't benefit of streaming; You may as well just use
>> network.curl for now, which is what i've seen used with hoauth.
>
> I don't really see why hoauth needs to make its own http requests at
> all, except perhaps as a convenience.  At heart, doesn't it just need to
> set up requests and parse certain responses?  It could almost be pure,
> aside from needing to get timestamps and generate nonces (which, btw,
> doesn't seem to be using a cryptographically strong RNG).  But that
> suffers from not having standard request/response types.
>
>> you should check the twidge twitter utility and/or yesod-auth-oauth, that both
>> uses curl/hoauth.
>
> Thanks for the pointers.  Does Network.Curl support interleaved
> processing on infinite streams?
>
>> It would be really useful to see an hoauth fully using enumerator and
>> http-enumerator (and not redefining a boat load of stuff), but IMO you'll need
>> to understand enumerators before tackling such a challenge.
>>
>> Also Wai is for abstracting server side "transport" (cgi/fastcgi/others),
>
> Yes, that's what I thought, but http-enumerator dips into it for its
> http response types.

This is something that Aristid has been working on with his http-types
package: it's supposed to be a more generic package that defines types
like HTTP status, request method, header key/value, etc. In the next
iteration of WAI/http-enumerator, they will both depend on http-types
most likely. But since http-types did not exist until recently,
http-enumerator borrowed the Status and CIByteString types from WAI.

I think in general it's a nice goal to get all HTTP client libraries
to accept identical interfaces, but in practice I don't think it can
ever happen.

>> the HTTP package doesn't do TLS.
>
> That's unfortunate, but it seems like it could have been a fairly easy
> thing to address.  Or does it have other deficiencies?

I've gotten a number of emails from people switching to
http-enumerator because it's faster than HTTP. Additionally, since
HTTP uses String instead of ByteString for its standard functions, it
can be very tricky to get character encodings correct.

The fact is, I wrote http-enumerator specifically to support OpenID
logins on haskellers.com, so in many ways it wouldn't surprise me for
it to be a good fit for hoauth.

On a separate, but related, note, I've been trying to consolidate a
number of third-party login systems (OpenID, Facebook, RPXNow) into a
single package called authenticate[1]. I hadn't actually noticed
hoauth until now, but it looks like it would be a perfect addition to
authenticate. There would basically be two ways to achieve this: 1)
have authenticate depend on hoauth or 2) move the code from hoauth to
authenticate. My guess is we would both prefer the first choice, but
I'd like to know if you are making any major API changes before doing
anything.

Michael

[1] http://hackage.haskell.org/package/authenticate



More information about the Haskell-Cafe mailing list