Hello Dojo,
We are trying to receive information through an API that returns a JSON. However, even though we can see the data in Wireshark, the DataMiner streamviewer returns an empty value. Additionally, when we send the data to the parameter ID, we see that the parameter is also blank.
Wireshark:
Stream Viewer:
We are trying to catch the response using:
<Response statusCode="502">
<Content pid="302"></Content>
</Response>
Are we missing something here?
Thanks!!
Edit:
José, I've tried before with application/json as Content-type with the same result. I've also try to add some other headers, delete them, try combinations...
Complete session:
<Session id="2" name="HTTP_REQUEST_GetStreams" loginMethod="credentials" userName="username" password="password">
<Connection id="1">
<Request verb="GET" url="/zixi/streams.json">
<Headers>
<Header key="Authorization">credentials</Header>
<Header key="User-Agent">DataMiner</Header>
<Header key="Accept">*/*</Header>
<Header key="Accept-Encoding">gzip, deflate, br</Header>
<Header key="Connection">keep-alive</Header>
<Header key="Content-Type">application/json</Header>
</Headers>
</Request>
<Response statusCode="502">
<Content pid="302"></Content>
</Response>
</Connection>
</Session>
From the network stream that you shared, it looks like you are trying to integrate a Zixi Broadcaster in DataMiner. Are you aware that we have a ready to use connector for that device in the DataMiner Catalog?
We have previously seen a similar issue with the same device and the root cause was the fact that it's using a deflate compression algorithm which WinHTTP (the engine that DataMiner is using in the background for HTTP communication) does not fully seem to be able to decompress.
It does not seem to be a generic issue because while it is not able to deflate these specific responses, it does seem to be able to deflate other responses. Other clients do seem able to deflate these actual responses so it is also not a compression issue at the device its side.
Another issue that we noticed is that it does not seem to respect the order of the algorithms defined in the Accept-Encoding request header. As soon as it notices the word deflate in there, it is going to use that one to compress even though gzip is preferred.
Can you try to force it to use gzip compression instead. You can do this by changing the Accept-Encoding request header definition to:
<Header key="Accept-Encoding">gzip</Header>
Hi Jeroen,
Thank you very much for your help. You are totally right; using gzip in the Accept-Encoding request header works perfectly. It seems that WinHTTP was using deflate instead of gzip without checking the order.
Thanks again!
Glad you got it working! Do note however that it's the Zixi Internal Web Server that is not interpreting the Accept-Encoding request header correctly and is always preferring deflate over gzip even though the order says differently. WinHTTP actually just decompresses the response based on what the web server decided and what is specified in the Content-Encoding response header.
Hi Dojo! has anyone had a similar experience? we are still facing the same problem after a lot of "headers-combination" test.
Thank you!