add a specific exception class for 401 errors
after a 401, refresh the token and then start a new HTTP connection

* We're getting some intermittent 408 timeouts from rackspace during file
  uploads. This is a stab in the dark, but I'm wondering if using the
  same persistent HTTP connection with the new token might be somehow
  causing an issue at rackspace's end
* rackspace *say* they support persistent connections, but who knows
here, have some brackets
the error class name should match the HTTP error name
use the Net::HTTP#start class method

* just a nice shorthand for Net::HTTP#new, and then #start
when retrying a request after a 401, create a new request object

* Previously, if rackspace returned a 401 we'd re-authenticate to get a
  fresh token and then retry the request
* crucially, we retried the request using *the same* Net::HTTP request
  object. That's fine for most requests, but for streaming_put, we use
  the body_stream feature to stream the upload (in case the upload is a
  large file). After the first attempt, it seems request.body_stream is
  set to nil, so the second attempt opens a connection but then seems to
  stall, causing rackspace to raise a 408 timeout after 60 seconds
* There might be a way to work around the mutation of the request
  object, but in the short term I've just decided to create a brand new
  request for the retry
add a script that reproduces the 408 timeouts on raca 0.3.1 and lower
spec that HttpClient#streaming_put will correctly retry after a 401
spec that HttpClient#head silently retries after a 401
spec that HttpClient#delete silently retries after a 401
spec that HttpClient#put silently retries after a 401
spec that HttpClient#post silently retries after a 401
extract building a streaming PUT request into a private method

* to avoid duplication
Merge pull request #1 from conversation/requests-are-mutable

Fix our 408 timeout errors
prepare a 0.3.2 release
remove automatic timeout retries from HttpClient

* these were an old (before raca was extracted into a gem) attempt to
  handle the 408 timeouts we were getting
* The 408s turned out to be a bug in our code (see cb14124), so this
  stuff isn't required anymore
add a User-Agent header to all requests

* I'm not sure if rackspace care, but we may as well do the right thing
remove a script I used to reproduce a bug

* the bug has been fixed and released in raca 0.3.2
stop using the ETag header on manifest uploads for large files

* The rackspace docs say:

    A similar situation applies to the ETag header. If it is used in the
    PUT operation, it must contain the MD5 checksum of the JSON content.

* despite that, I'm finding that including the ETag header results in
  rackspace returning a 422 error.
* We're probably doing something wrong, but damned if I can pick it. In
  the short term, best to just remove the ETag header from manifest
  uploads (it's optional) to get large file uploads working again
The correct header is ETag, not Etag