search

estately / rets

A pure-ruby library for fetching data from RETS servers
https://github.com/estately/rets
127 stars 94 forks source link

"401/RETS-Session-ID is invalid" errors #169

Closed danwoolley closed 6 years ago

danwoolley commented 8 years ago

Are you guys seeing this issue? This past week, we've been getting this message intermittently from Rapattoni RETS servers. I can make it happen fairly consistently in BAREIS by running a specific rspec test multiple times in a row. The query for data goes just fine, but when you use GetObject to get binary photos (urls are not available), the first several work just fine, but then this response comes from the rest:

HTTP/1.1 401 RETS-Session-ID is invalid.

There's one header value from the server that changes between successful and failed requests:

X-Powered-By: ASP.NET (L004)

to this:

X-Powered-By: ASP.NET (L002)

My theory is a load-balancer is passing us from one server to another, and the RETS-Session-ID is not recognized on the new server. This might really be a server side issue, but my question is do you feel like that is a valid server response that may happen from time to time for whatever reason, and we should be handling that somehow? It looks like the server dictates this cookie on the login response, then we just include it in responses from then on.

Right now, the gem retries that getobject three times, then does a new login, but the same RETS-Session-ID in the header continues to be used, so the getobject fails again three times, and that repeatedly happens for all subsequent attempts.

Maybe that RETS-Session-ID should be purged when we get that error response? Not sure how we would get a new one going forward though. Maybe that error requires a reset session with a whole new login?

Just wanted your feedback before I spend time poking around the code.

dougcole commented 8 years ago

I haven't noticed that exact scenario myself, although I have seen that error before.

I haven't studied this enough to give great feedback, but it does seem odd that we'd keep the same RETS-Session-ID header between logins.

timdorr commented 8 years ago

I'm seeing this with GFLR, who is on RAGFL's RETS server and uses RETSIQ as their vendor. I've been meaning to do a deeper dive into why the session is retained, but I've got looming deadlines that are pushing that back.

For now, I'm just using find_every and handling the retry logic myself. Personally, I think the find_with_retries should be an opt-in behavior, as I don't really want to be hammer these relatively fragile RETS servers with bad requests by default.

norman commented 6 years ago

Closing this as stale for now.