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.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
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.
