Querying multiple values for a field
I've started getting 500 Errors when when doing a query containing this: (L_Area=|2,18,25,45,56,75,78,86,94,131) It will work if I cut it down to just 2 values: (L_Area=|2,18)
I'm having a similar issue with status: (L_Status=|1_0,3_0,1_1) doesn't work but (L_Status=|1_0,3_0) does.
It has the same issue with and without the |.
It has run correctly for years but it started failing Nov 12. Also, it is across multiple MLS providers so it is like an issue on the Paragon side of things.
I am seeing a similar issue on different fields across all MLSs. Seems to have started on Saturday morning. For example, this returns a 500:
We're basically dead in the water across the board since our sync jobs are all dying.
I'm using this workaround for now. ((L_Status=1_0)|(L_Status=3_0)|(L_Status=1_1))
What account name are you using?
I tested it with another account and your original queries work without issue.
our login is T101597
I don't see that account on SJSR?
that login is for this:
As I said this problem suddenly started happening for all MLSs on Saturday .We're also seeing login timeouts intermittently.
NGLRMLS with your account and the area search listed above worked fine.
Status search (L_Status=|1_0,3_0,1_1) also worked without issue.
look in your logs at our requests for that login since saturday. Also we don't search on L_Status.
I am also able to replicate the original issue in this thread.
We get a connection reset by peer error. I have to wonder if there isn't some sort of network or security issue at play here. When we make queries from AWS they all fail on this error.
OR actually, maybe this is a credentials issue?
RAW Request from Fiddler:
GET http://nglrmls.rets.paragonrels.com/r... HTTP/1.1 Host: nglrmls.rets.paragonrels.com RETS-Version: RETS/1.5 Accept: / User-Agent: Top Producer/1.0 Cookie: RETS-Session-ID=-883ee5ce-d9a5-4d9a-879a-a7f456206ecc-
HTTP/1.1 401 Unauthorized Cache-Control: private Content-Type: text/html Expires: Mon, 01 Jan 0001 00:00:00 GMT RETS-Server: RETS-Paragon/1.0 RETS-Version: RETS/1.5 WWW-Authenticate: Digest qop="auth",realm="NGLRMLS",nonce="2022-11-14T18:48:00",opaque="",stale="false",domain="\rets\fnisrets.aspx\nglrmls" X-Server: A070-01 Date: Mon, 14 Nov 2022 18:37:59 GMT Content-Length: 1293 Vary: Accept-Encoding
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>401 - Unauthorized: Access is denied due to invalid credentials.</title> <style type="text/css"> </style> </head> <body>
401 - Unauthorized:
This happening for me on CAAR and NRV. I've confirmed that office search example also doesn't work for me. It is definitely not an auth issue. If I remove that part of the query it works and if I write it out long form ((L_Status=1_0)|(L_Status=3_0)|(L_Status=1_1))
(L_Status=|1_0,2_0) works with 2 values. Once you add the 3rd one it breaks.
ok, so the pattern seems consistent. If I do this the query works fine:
but if I do this:
we run into the errors.
Another example... This query:
returns a 500 error, but this version works fine:
Can you comment? It doesn't help that it works on your end. If you check out the logs something should be obvious. We haven't changed anything on this end.
I was able to run both of those NGLRMLS queries you listed with your account without issue.
That's not very helpful. What would be helpful, is if you could examine your logs and see why we get a 500 error on the first version. Something has changed on your end and it needs to be investigated. If you are unwilling to do anything else please be clear and let me know so we're no waiting on you.
I should add, I didn't open this thread, it was weezer311 who is experiencing the same problem starting on the same day as us. If it was only us complaining maybe if I were you I would be a little skeptical, but this is not the case and no doubt others may be experiencing this problem as well.
Are you having this issue on more than NGLRMLS?
If so, what other MLS's?
yes, the same issue for 60+ MLSs.
Can you try http://caar-rets.paragonrels.com/rets...
It doesn't work on CAAR and NRV but does work on CGAR and CWTAR.
odd, it doesn't seem to work for us for anything
And it does work on SCWMLS. So 2 out of 5 have the same issue.
Can you try switching to RETS/1.7.2 or RETS/1.8 and see if it makes a difference?
I do see lots of successful requests coming through on NGLRMLS.
Switching to 1.8 did not fix it for me on CAAR or NRV.
yeah, that doesn't seem to matter
Are both weezer311 and jflaig from the same company or different ones?
The NGLRMLS query from above: (L_ListingID=1%2b),((L_StatusCatID=1)|(L_StatusCatID=3)),(L_DisplayId="1905045","1906612","1906613","1906610")
Where you said you get the 500 error.
What day was that sent?
I'm trying to track it down in the logs.
today. shortly before I posted the message
but we're hitting searches every 15 minutes for NGLRMLS using that format that are failing. so you should see it all over for that login.
I've tested it a bunch today on CAAR. I just did one right before posting this.
I'm trying to focus on NGLRMLS at the moment instead of jumping all around.
But what application or library are you both using to connect to RETS?
we're using custom RETS client hosted in AWS. I would guess weezer311 is doing something else. It's worked fine up until Saturday.
Is it using multiple IP addresses in AWS?
If so, it could be that some are being blocked.
In my logs I show for NGLRMLS these two: many with: 184.108.40.206 and a very few with: 220.127.116.11
Mine is custom written coming from a Rackspace server. In my case it is a single IP and it is not being blocked. I can toggle back and forth from the working and non working query. Additionally the 3 working sites are coming from the same IP. I would expect an error in the 400 range if it was a block. 500 error indicates that it is an issue on the server side where some fatal error is not caught.
@weezer311 what MLS and account name are you having the issue with?
CAAR with user CAAR_RETS_19
You can ignore the 18.104.22.168, that's my local. The AWS IP is 22.214.171.124. I believe our requests should only be coming from one IP in AWs.
@jflaig Can you try the same request that you get the 500 error in a browser?
Do the login request making sure to pass the RETS-Version parameter in the URL.
Then change it to search and pass your failing search parameters along with the RETS-Version parameter and see if you get the exact same error that way too?
While waiting for @jflaig I've confirmed mine fails the same way in a browser.
@weezer311 so you get the same 500 error in the browser?
Can you give me the exact CAAR query you are using for your test?
Yes. I've figured out the issue. It works when encoding the commas as %2C. So something changed recently that requires more than one comma to need to be URL encoded. The ones that were working for me had no more than one comma in the values.
That is weird. We haven't changed anything on our side recently.
When I send my requests out they aren't encoding the commas.
I tried it both with POST request and in a browser URL and it worked in both cases.
So it doesn't really answer the why or what changed that would cause yours to break.
I'm sure we would have heard from many more vendors if it were a far reaching issues.
Try changing the domain in your rets URL to "nglrmls-rets.paragonrels.com" with the DASH in it
Then see if your query works without escaping the quotes.
I ran that exact query and it doesn't work for me. When I change the commas to %2C it does work.
This is the URL I am using. caar-rets.paragonrels.com I don't have NGLMLS.
You tried it with the DASH instead of period in the domain name?
Try it with HTTPS instead of HTTP.
Make sure to set to BASIC authentication for HTTPS.
I was just testing that. The 2 that weren't working were using HTTP. I changed them to HTTPS and it works with multiple commas.
the version and using https doesn't seem to matter on our end. So what is the take away, that we now have to encode the commas?
@jflaig Were you able to successfully login with HTTPS?
And with HTTPS, did you get the exact same error when commas were included?
Make sure the domain name has the DASH and NOT the DOT when using HTTPS.
Yes. That fixed the original issue.
yes, but using http vs https seems to have no bearing on this issue, although is weezer311 is saying it fixed the original issue, there is one thing I can try befoire totally ruling that out. Hang on.
Switching from HTTP to HTTPS is what solved the issue of 500 error when passing in more than 2 values separated by commas. Typically I would think these would both being going to the same endpoint but it seems that they are different. Ultimately they should be HTTPS anyway. I just missed converting a few over.
we have RETS sessions manager which caching the session info, so I have to wait for that to expire for the change to https to take affect.
do you know why I would get this error:
The remote certificate is invalid according to the validation procedure.
trying this https url:
You should see the errors from the last 10 minutes from this ip: 126.96.36.199
If you change nglmls.rets to nglmls-rets the SSL will be valid.
I can get that URL to work, but I have to ignore the error basically, which in .Net is done like so when setting up the HttpClient to make the login request:
handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
ok, I will try that
ok, I think the dash and https solves the problem for us.