Fix decode HTTP content-encoding#1413
Conversation
|
So I found out that node-fetch is supposed to handle gzip. Therefore i am not sure why it does not work with my example API. |
|
General comment: IF we need to tackle compression separately, I wonder whether such a generic method like |
@relu91 do you know more? |
|
I reviewed the issue. Here are my findings:
Therefore, I'd keep the issue, but I would fix it by upgrading the HTTP client implementation with the new Node.js native fetch api (which is also cross-platform). However, for node 20, we should set the flag |
|
Thanks @relu91 for the clarifications! If you want, I can close this PR and open an issue instead. |
|
@danielpeintner are you ok to close this PR and open an issue? |
If I understand the proposal correctly, we wait for May 2026 (Node.js no longer maintained) and switch to native fetch Either way is fine by me. |
Yes, it depends on user pressure. I tend to prefer fixing it now, but waiting is also ok.
Ok then, let's close this. |
@FreuMi if you don't mind, can you create the issue? |
3 participants
Hi everyone!
Problem:
When consuming endpoints that return compressed payloads, the HTTP binding currently forwards the compressed bytes directly to the codecs. This causes parsing/validation errors since the codecs expect plain data.
For example, this public datetime API:
responds with:
With the current HTTP binding, the JSON codec receives compressed bytes and fails with errors such as:
Here is the TD I used to reproduce the issue:
{ "@context": "https://www.w3.org/2022/wot/td/v1.1", "title": "dateTimeAPI", "securityDefinitions": { "nosec_sc": { "scheme": "nosec" } }, "security": ["nosec_sc"], "properties": { "currentDateTime": { "description": "Get current datetime", "readOnly": true, "type": "object", "properties": { "datetime": { "type": "string", "format": "date-time" } }, "forms": [ { "href": "https://aisenseapi.com/services/v1/datetime", "contentType": "application/json" } ] } } }Fix:
The HTTP client now checks the
content-encodingresponse header and transparently decompresses the payload before passing it to the codecs. I added a helper inhttp-client-impl.tsto handle this logic when a response is compressed.I thought this fix could be useful for others too.