[Haskell-cafe] Contributing to http-conduit

[Myles C. Maxfield]

Here is a patch regarding getRedirectedRequest. Comments are very welcome.

--Myles C. Maxfield

On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield <
myles.maxfield at gmail.com> wrote:

> I was planning on making the caller deal with keeping track of cookies
> between requests. My cookie idea only solves the problem of cookies
> persisting through a redirect chain - not between subsequent request chains.
>
> Do you think that Network.HTTP.Conduit should have a persistent cookie jar
> between caller's requests? I don't really think so.
>
> --Myles
>
>
> On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman <michael at snoyman.com>wrote:
>
>> On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield
>> <myles.maxfield at gmail.com> wrote:
>> > Alright, that's fine. I just wanted to be explicit about the interface
>> we'd
>> > be providing. Taking the Request construction code out of 'http' and
>> putting
>> > it into its own function should be a quick change - I'll have it to you
>> > soon. One possible wrench - The existing code copies some fields (like
>> the
>> > proxy) from the original request. In order to keep this functionality,
>> the
>> > signature would have to be:
>> >
>> > checkRedirect :: Request m -> Response -> Maybe (Request m)
>> >
>> > Is that okay with you? I think I'd also like to call the function
>> something
>> > different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add
>> an
>> > example to the documentation about how a caller would get the
>> redirection
>> > chain by re-implementing redirection (by using the example in your
>> previous
>> > email).
>>
>> Sounds great.
>>
>> > As for cookie handling - I think Network.Browser has a pretty elegant
>> > solution to this. They allow a "CookieFilter" which has type
>> > of URI -> Cookie -> IO Bool. Cookies are only put in the cookie jar if
>> the
>> > function returns True. There is a default CookieFilter, which behaves
>> as we
>> > would expect, but the user can override this function. That way, if you
>> > don't want to support cookies, you can just pass in (\ _ _ -> return
>> False).
>>
>> Also sounds good.
>>
>> > If we're already expecting people that want specific functionality to
>> > re-implement the redirect-following code, this solution might be
>> > unnecessary. Do you think that such a concept would be beneficial for
>> > Network.HTTP.Conduit to implement?
>>
>> Yes, I can imagine that some people would want more fine-grained
>> control of which cookies are accepted.
>>
>> > Either way, I'll probably end up making a solution similar to your
>> > checkRedirect function that will just allow people to take SetCookies
>> out of
>> > a Response and put Cookies into a Request. I'll probably also provide a
>> > default function which converts a SetCookie into a cookie by looking up
>> the
>> > current time, inspecting the Request, etc. This will allow me to not
>> have to
>> > change the type of Request or Response - the functions I'll be writing
>> can
>> > deal with the raw Headers that are already in Requests and Responses.
>> > Modifying 'http' to use these functions will be straightforward.
>> >
>> > How does this sound to you?
>>
>> Sounds like a good plan to me. I'm not entirely certain how you're
>> planning on implementing the cookie jar itself. In other words, if I
>> make a request, have a cookie set, and then make another request
>> later, where will the cookie be stored in the interim, and how will
>> the second request know to use it?
>>
>> Michael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120126/a7a4411d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getRedirectedRequest.patch
Type: application/octet-stream
Size: 6487 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120126/a7a4411d/attachment-0001.obj>