Re: [Haskell-cafe] Contributing to http-conduit

the fromJust should never fail, beceause of the guard statement: | 300 <= code && code < 400 && isJust l'' && isJust l' = Just $ req Because of the order of the && operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? Thanks, Myles On Thu, Jan 26, 2012 at 12:59 AM, Michael Snoyman wrote:

I'm a little worried about the use of `fromJust`, it will give users a very confusing error message, and the error might be trigged at the wrong point in the computation. I'd feel better if checkRedirect lived in either some Failure, an Either, or maybe even in IO itself. IO might make sense if we want to implement some cookie jar functionality in the future via mutable references.

Michael

...

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 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 wrote:

...

On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield 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

On Thu, Jan 26, 2012 at 10:29 AM, Myles C. Maxfield wrote: 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