Skip to main content
  • EN

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?

 

image

Did you specify any custom headers in Postman?

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 link https://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 link https://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.

Thanks @debbiatsafe​ that worked. 😀 👍

 

image

Reply


Community Stats

30,168
Posts
114,529
Replies
37,827
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.