Solved

HTTPCaller Fail with Waze Partner Hub API

  • 21 April 2022
  • 3 replies
  • 16 views
peteratqfes
Rank
Badge +1

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

icon

Best answer by debbiatsafe 21 April 2022, 21:17

View original

3 replies

david_r
Rank
Userlevel 4

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.

debbiatsafe
Rank
Userlevel 3
Badge +17

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.

peteratqfes
Rank
Badge +1

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

28,669
Posts
109,361
Replies
36,531
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.