When you capture the response stream, and save it to a file or view it in a browser, you would likely find that you are getting an HTTP 500 Server Error page, and further it would tell you that you were doing something they claim is "Cookie Poisoning."
That error page includes an email address where you can contact their RETS Technical Support, and I suggest you do so immediately.
The issue comes down to how the Apache HttpClient 3.x handles cookies. retsIQ uses the 3.x version, and the default is to be RFC 2109 compliant - which is consistent with the RETS specification since 1.7.
MRIS is not RFC 2109 compliant. In talking with their support, they quote RFC 6265, which is the most recent RFC on Cookies. However, RETS 1.7 to 1.8 is very clear "The client MUST implement cookie handling as specified in
RFC 2109." To make matters worse, they see RFC 2109 compliance as cookie poisoning.
Your dilemma is that retsIQ hides the API you need to modify the CookiePolicy to either CoookiePolicy.NETSCAPE
or CookiePolicy.BROWSER_COMPATIBILITY
.
You have three choices (in order of feasibility and your ability to control the outcome):
- Alter your application to use libRETS.
- Use reflection to intercept/modify the HttpState of the HttpClient to modify the CookiePolicy.
- Wait for MRIS to stop claiming RFC 2109 compliant cookies are malformed.