Support specifying cookies in the faraday connection

[knewter]

What are your thoughts on adding an API to allow one to set cookies on the connection?

Here's the use case - we had three people running a bit of code that's a big heavy on the mt. gox api. Mt. Gox uses "I'm Under Attack Mode" with CloudFlare. An undocumented feature of that mode (or at least I couldn't find it, but #mtgox channel mentioned it) was that if CF thinks you're DDoSing they'll flip a bit on your IP and require you to perform a javascript-based unit of work, set a cookie in your browser, and then let you in.

As it stands, from one IP we have to send a given cookie across or our API calls fail. I've got a monkeypatch in place in my project right now to support adding cookies into the header (in both get and post requests), but it seems like it could come up for other users of your API client as well.

[knewter]

I'm also going to be writing a (horrendous) headless webkit client in my app that catches this error if it occurs, performs the in-browser unit of work headless, sets a configuration option in a file and replaces the in memory cookie, on the off chance that this happens again. That's not terribly relevant to this ticket, but it's also not likely something I'll open source for fear that it would upset CloudFlare, etc.

I'm not DDoSing them, at all, and actually have relatively normal looking API usage, but we have a tool that fetches the history for all time to bootstrap a database table full of mt. gox trades, and when a new dev came on board and bootstrapped his environment while two of us were also hitting the api fairly heavily, cloudflare laid down the hammer.

[sferik]

If you put the code into a pull request, I'll review it.

[knewter]

So for my use case, this wasn't nearly as useful as it appeared 3 months ago. I'll close it (I implemented it, but it was Not Pretty and I removed it).