refindlyllc / rets

A thin RETS client
MIT License
69 stars 26 forks source link

Get system metadata RETSException #194

Closed giovannirescia closed 6 years ago

giovannirescia commented 6 years ago

Hi all,

Am trying to follow the tutorial in the README, but am getting RETSException: Different RETS version within a session is not allowed when trying to get the system's metadata, trying to get a resource's metadata yields the same, I assume that the nature of the problem is the same.

Any idea why this might be happening?

Cheers, G.

mcrowson commented 6 years ago

I think the session object defaults to version 1.5. I don't see how the version can change within a session though. Do you have the series of calls you make that caused it? Have you tried manually setting the version when you instantiate the session?

giovannirescia commented 6 years ago

@mcrowson I tried with both versions 1.5 and 1.7.2. This in the only thing I ran:

rets_client = Session(login_url, username, password, version='1.7.2')
rets_client.login()
system_data = rets_client.get_system_metadata()

BTW I am using Python 3.6.

mcrowson commented 6 years ago

login at RETSMD and see what version the login page gives back. https://retsmd.com/

giovannirescia commented 6 years ago

1.5, which is set by default, but I was able to connect with the 1.7.2 version also.

mcrowson commented 6 years ago

ok interesting. When you log into retsmd it is making that same get_system_metadata call under the hood (well, the PHP library version of it). If you can step through the requests and responses that the library is making/receiving it might help figure out how this is all playing out with that rets server and your credentials.

giovannirescia commented 6 years ago

Well, I tried a few things but didn't work. I compare it with this RETS library and tried to mimic it, in both sides the headers of the sessions were the same:

# other lib
self._session.headers
{'User-Agent': 'python-requests/2.18.4', 'Accept-Encoding': 'gzip, deflate', 'Accept': '*/*', 'Connection': 'keep-alive'}

# yours
self.client.headers
{'Accept': '*/*',
 'Accept-Encoding': 'gzip, deflate',
 'Connection': 'keep-alive',
 'RETS-Version': 'RETS/1.7.2',
 'User-Agent': 'Python RETS'}

Also the HTTP query was the same:

# other lib
ipdb> pp url
'http://alt-calrets.mlslistings.com:6103/GetMetadata.ashx'
ipdb> pp headers
{'RETS-Version': 'RETS/1.7.2', 'User-Agent': 'rets-python/0.3'}
ipdb> pp payload
{'Format': 'COMPACT', 'id': '0', 'type': 'METADATA-SYSTEM'}

# yours
ipdb> pp url
'http://alt-calrets.mlslistings.com:6103/GetMetadata.ashx'
ipdb> pp options
{'headers': {'RETS-Version': 'RETS/1.7.2', 'User-Agent': 'Python RETS'},
 'query': {'Format': 'COMPACT', 'ID': '0', 'Type': 'METADATA-SYSTEM'}}

In both cases the requests library version is 2.18.4.

I experimented within my limitations, any idea what else to try?

giovannirescia commented 6 years ago

Solved it. The anomaly was in the function login in session.py:

if parser.headers.get('RETS-Version') is not None:
    self.version = str(parser.headers.get('RETS-Version'))
    self.client.headers['RETS-Version'] = self.version

The server was returning the version as RETS/1.7.2 instead of just 1.7.2.

Thank you for support!