the fromJust should never fail, beceause of the guard statement:<div><br></div><div> | 300 <= code && code < 400 && isJust l'' && isJust l' = Just $ req</div><div><br></div><div>
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.</div>
<div><br></div><div>Knowing that, I don't quite think I understand what your concern is. Can you elaborate?</div><div><br></div><div>Thanks,</div><div>Myles</div><div><br><div class="gmail_quote">On Thu, Jan 26, 2012 at 12:59 AM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm a little worried about the use of `fromJust`, it will give users a<br>
very confusing error message, and the error might be trigged at the<br>
wrong point in the computation. I'd feel better if checkRedirect lived<br>
in either some Failure, an Either, or maybe even in IO itself. IO<br>
might make sense if we want to implement some cookie jar functionality<br>
in the future via mutable references.<br>
<br>
Michael<br>
<br>
On Thu, Jan 26, 2012 at 10:29 AM, Myles C. Maxfield<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>> wrote:<br>
> Here is a patch regarding getRedirectedRequest. Comments are very welcome.<br>
><br>
> --Myles C. Maxfield<br>
><br>
><br>
> On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield<br>
> <<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>> wrote:<br>
>><br>
>> I was planning on making the caller deal with keeping track of cookies<br>
>> between requests. My cookie idea only solves the problem of cookies<br>
>> persisting through a redirect chain - not between subsequent request chains.<br>
>><br>
>> Do you think that Network.HTTP.Conduit should have a persistent cookie jar<br>
>> between caller's requests? I don't really think so.<br>
>><br>
>> --Myles<br>
>><br>
>><br>
>> On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield<br>
>>> <<a href="mailto:myles.maxfield@gmail.com">myles.maxfield@gmail.com</a>> wrote:<br>
>>> > Alright, that's fine. I just wanted to be explicit about the interface<br>
>>> > we'd<br>
>>> > be providing. Taking the Request construction code out of 'http' and<br>
>>> > putting<br>
>>> > it into its own function should be a quick change - I'll have it to you<br>
>>> > soon. One possible wrench - The existing code copies some fields (like<br>
>>> > the<br>
>>> > proxy) from the original request. In order to keep this functionality,<br>
>>> > the<br>
>>> > signature would have to be:<br>
>>> ><br>
>>> > checkRedirect :: Request m -> Response -> Maybe (Request m)<br>
>>> ><br>
>>> > Is that okay with you? I think I'd also like to call the function<br>
>>> > something<br>
>>> > different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add<br>
>>> > an<br>
>>> > example to the documentation about how a caller would get the<br>
>>> > redirection<br>
>>> > chain by re-implementing redirection (by using the example in your<br>
>>> > previous<br>
>>> > email).<br>
>>><br>
>>> Sounds great.<br>
>>><br>
>>> > As for cookie handling - I think Network.Browser has a pretty elegant<br>
>>> > solution to this. They allow a "CookieFilter" which has type<br>
>>> > of URI -> Cookie -> IO Bool. Cookies are only put in the cookie jar if<br>
>>> > the<br>
>>> > function returns True. There is a default CookieFilter, which behaves<br>
>>> > as we<br>
>>> > would expect, but the user can override this function. That way, if you<br>
>>> > don't want to support cookies, you can just pass in (\ _ _ -> return<br>
>>> > False).<br>
>>><br>
>>> Also sounds good.<br>
>>><br>
>>> > If we're already expecting people that want specific functionality to<br>
>>> > re-implement the redirect-following code, this solution might be<br>
>>> > unnecessary. Do you think that such a concept would be beneficial for<br>
>>> > Network.HTTP.Conduit to implement?<br>
>>><br>
>>> Yes, I can imagine that some people would want more fine-grained<br>
>>> control of which cookies are accepted.<br>
>>><br>
>>> > Either way, I'll probably end up making a solution similar to your<br>
>>> > checkRedirect function that will just allow people to take SetCookies<br>
>>> > out of<br>
>>> > a Response and put Cookies into a Request. I'll probably also provide a<br>
>>> > default function which converts a SetCookie into a cookie by looking up<br>
>>> > the<br>
>>> > current time, inspecting the Request, etc. This will allow me to not<br>
>>> > have to<br>
>>> > change the type of Request or Response - the functions I'll be writing<br>
>>> > can<br>
>>> > deal with the raw Headers that are already in Requests and Responses.<br>
>>> > Modifying 'http' to use these functions will be straightforward.<br>
>>> ><br>
>>> > How does this sound to you?<br>
>>><br>
>>> Sounds like a good plan to me. I'm not entirely certain how you're<br>
>>> planning on implementing the cookie jar itself. In other words, if I<br>
>>> make a request, have a cookie set, and then make another request<br>
>>> later, where will the cookie be stored in the interim, and how will<br>
>>> the second request know to use it?<br>
>>><br>
>>> Michael<br>
>><br>
>><br>
><br>
</div></div></blockquote></div><br></div>