We're trying to tap into the Waze's partner hub Traffic Data using their GeoRSS XML feed.
The feed downloads fine in Chrome and Postman.
It's a simple GET request. But I get the following error in the log.
"HTTP transfer error: Unrecognized or bad HTTP Content or Transfer-Encoding"
When tested in Curl I had to include the ssl-no-revoke argument to allow it to download (might be caused by our funky certificate store). "The revocation function was unable to check revocation for the certificate."
I have "Verify SSL Certificates" set to No in the HttpCaller.
Any ideas? Is it related to the ssl-no-revoke?
Best answer by debbiatsafe
It was found that GeoRSS response from Waze was malformed in previous reported cases, as the response returns UTF-8 as the value for the Content-Encoding header. This linkhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding does not include UTF-8 as a valid value for this header.
Unlike Postman or web browsers, the library that FME uses for HTTP is strict and will error with malformed responses.
Are you able to check in Postman and see if Content-Encoding: UTF-8 is present in the response header?
If it is present, our development team had added a custom header Accept-Encoding for the HTTPCaller. A blank value for this header will turn off automatic decoding of the response.
You can try to enable debug messages in the FME log and re-run the workspace. The log should now contain more details about the connection, which you could consider posting here.
It was found that GeoRSS response from Waze was malformed in previous reported cases, as the response returns UTF-8 as the value for the Content-Encoding header. This linkhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding does not include UTF-8 as a valid value for this header.
Unlike Postman or web browsers, the library that FME uses for HTTP is strict and will error with malformed responses.
Are you able to check in Postman and see if Content-Encoding: UTF-8 is present in the response header?
If it is present, our development team had added a custom header Accept-Encoding for the HTTPCaller. A blank value for this header will turn off automatic decoding of the response.
It was found that GeoRSS response from Waze was malformed in previous reported cases, as the response returns UTF-8 as the value for the Content-Encoding header. This linkhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding does not include UTF-8 as a valid value for this header.
Unlike Postman or web browsers, the library that FME uses for HTTP is strict and will error with malformed responses.
Are you able to check in Postman and see if Content-Encoding: UTF-8 is present in the response header?
If it is present, our development team had added a custom header Accept-Encoding for the HTTPCaller. A blank value for this header will turn off automatic decoding of the response.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.
