You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 13, 2023. It is now read-only.
Method 'request(options: IRestOptions): Promise ' in zowe/imperative/tree/next/packages/rest/src/client/AbstractRestClient.ts
Returns binary data in causeErrors field of the error response returned when HTTP status code is outside the 200 range.
This is a breaking change from previous versions of imperative (well, so be it) and also means that plugins that need to read the REST response need to convert it to text - so the unzipping is handled by Imperative if responses are in the 200 range, but plugins still need to handle it to get to any error messages returned from a REST API when the status code is higher.
Is this fixable, planned to be fixed, or should plugins work around the issue?
Thanks,
Michal Vasak
Broadcom
The text was updated successfully, but these errors were encountered:
Thanks for reporting this. I've investigated and it seems that AbstractRestClient only parses content-encoding headers in the case of request success and ignores them on request failure. This should be fixable and I'll start working on a fix.
Method 'request(options: IRestOptions): Promise ' in zowe/imperative/tree/next/packages/rest/src/client/AbstractRestClient.ts
Returns binary data in causeErrors field of the error response returned when HTTP status code is outside the 200 range.
This is a breaking change from previous versions of imperative (well, so be it) and also means that plugins that need to read the REST response need to convert it to text - so the unzipping is handled by Imperative if responses are in the 200 range, but plugins still need to handle it to get to any error messages returned from a REST API when the status code is higher.
Is this fixable, planned to be fixed, or should plugins work around the issue?
Thanks,
Michal Vasak
Broadcom
The text was updated successfully, but these errors were encountered: