dynect_rest icon indicating copy to clipboard operation
dynect_rest copied to clipboard

Occasional 307 redirects not being followed correctly

Open gandelman-a opened this issue 14 years ago • 1 comments

I've found somewhere around 99/100 requests to dynect end up in a 307 redirect. It looks like commit 9e331d5de83b1fe3ec8f added a get() call to follow that redirect, but sends the full redirect (ie, /REST/Job/1039124) to get(), which ends up prepending another /REST/ to the URI. I've tried cleaning myself so that get() gets 'Job/1039124', but this call results in an Invalid Token error. In any case, the failed redirects still succeed. This my first time working with both Ruby and REST and I'm unsure how to debug further. For now, I'm just re-trying the request in the event of 307.

gandelman-a avatar Jan 26 '11 20:01 gandelman-a

We've seen this behavior as well: a 307 Temporary Redirect is being treated as a failure by the dynect_rest gem, even though on the server side it is a success. In our case specifically, we are attempting to publish a DNS zone; and the Dyn API returns a "307 Temporary Redirect: Job/1715909563" response, but in the Dyn zone log, we can see that the operation itself was a success on the Dyn side (the zone was published with the expected changes in-place).

The interesting thing is that the response from the Dyn API is not being properly caught by the code in dynect_rest.rb. Specifically, our stacktrace looks like this:

vendor/bundle/ruby/2.1.0/gems/dynect_rest-0.4.6/lib/dynect_rest.rb:233:in `rescue in api_request': Request failed: 307 Temporary Redirect: Job/1715909563 (DynectRest::Exceptions::RequestFailed)
    from vendor/bundle/ruby/2.1.0/gems/dynect_rest-0.4.6/lib/dynect_rest.rb:221:in `api_request'
    from vendor/bundle/ruby/2.1.0/gems/dynect_rest-0.4.6/lib/dynect_rest.rb:216:in `put'
    from vendor/bundle/ruby/2.1.0/gems/dynect_rest-0.4.6/lib/dynect_rest.rb:121:in `publish'

I would have expected a 307 to be caught by the check for if e.http_code == 307 on line 228 of dynect_rest.rb, however that is clearly not the case given the above stacktrace.

Is it possible that the Dyn API is returning a "307 Temporary Redirect" that doesn't actually have e.http_code == 307?

rbroemeling avatar Jun 24 '15 16:06 rbroemeling