<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body>
<span id="mailbox-conversation"><div>One of the reasons I like (and extensively use) Gun is precisely because it does NOT automatically do stuff like track cookies for you or follow redirects. </div>
<div><br></div>
<div>In the past we have used a seemingly endless train of Erlang HTTP clients and been tripped up when they try to be too helpful (retrying requests under the covers etc.) There is plenty of room for helper libraries on top of things like gun (such as shotgun - internally we have one called spud_gun), but I’m always nervous when the low level library tries to “help”. Already gun by default sends keep alive messages that break e.g. API calls to AWS (Amazon terminates the tcp connection when it notices it has inbound data that its API says should not be there).</div>
<div><br></div>
<div>I could just about see cookie handling as falling the right side of the “does too much for you” line, but have a strong preference that helper functionality is clearly separated from the underlying core.</div>
<div><br></div>
<div>Big fan of Gun / Cowboy so absolutely no criticism intended - but you did say “suggestions welcome”.</div>
<div><br></div>
<div>Adrian</div>
<br><span id="orc-full-body-initial-text" style="display:inline;">On Friday, Jun 12, 2015 at 1:44 pm, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>, wrote:<br></span></span><span class="none"><blockquote class="gmail_quote">On 06/12/2015 02:19 PM, Mikl Kurkov wrote:<br>> On Fri, Jun 12, 2015 at 1:39 AM, Loïc Hoguin <essen@ninenines.eu<br>> <mailto:essen@ninenines.eu>> wrote:<br>><br>> Right we do want to have a cookie store later on. I am not sure how<br>> this is supposed to look yet though. Suggestions welcome, I believe<br>> there is a ticket for it.<br>><br>><br>> I'm afraid it will not be easy to find solution that will fit all user<br>> cases.<br>> Someone need few huge client sessions, keeping cookies for many sites in<br>> ETS or even SQL database.<br>> It seems httpc optimized for this use case.<br>> In my case I need many tiny isolated sessions, so it is possible to have<br>> session store in state.<br>> That's why I like xhttpc approach - you get some stable API and can use<br>> different implementations for<br>> say cookie store that fits your needs.<br><br>The way I see it is that Gun needs to keep track of cookies for the <br>current connection *and* send cookies to the user process if any other <br>kind of tracking is required. Feeding cookies back into the Gun process <br>should be a function call or option away.<br><br>-- <br>Loïc Hoguin<br>http://ninenines.eu<br>_______________________________________________<br>erlang-questions mailing list<br>erlang-questions@erlang.org<br>http://erlang.org/mailman/listinfo/erlang-questions<br>
</blockquote></span>
</body></html>