Can you confirm that the field with this date is a field of type date and not text?
Can you post an example of the code used in the web app to perform the find?
I can confirm that the field is a field of type Date.
I've just requested a copy of the code. I'll pass it on when I receive it.
I think we've traced the bug correctly and we can say that it is not a Filemaker Server problem.
It’s because the middleware is encoding the date argument due to the / characters.
When you make a request via http- the filemaker server returns a http redirect (301 or 302) and the client makes another request to the new https address.
On the second request the url gets re-encoded, and if the url is already encoded it gets mangled.
Eg: Find an event 09/05/2013 using an encoded url – gives a filemaker 500 error because the date in the url gets encoded twice.
09%2f05%2f2013 becomes 09%252f05%252f2013, ie: the % sign in the original encoded date gets reencoded to %25
When filemaker decodes this it sees 09%2f05%2f2013 – which is an invalid date.
However, this request succeeds because the date is not reencoded
When I used the date format 09-05-2013 – it succeeds because the date is not encoded as – is a valid character in a URL
However, to find a date greater than eg: >=09-05-2013, >= gets encoded to %3E%3D which causes a problem when reencoded due to the redirect.
When the request is made via https, no redirect occurs so the url doesn’t get mangled by reencoding.
so it's not a bug in FileMaker.