This refactoring effort centralizes and standardizes header generation across the SDK and CLI, consolidating all header logic into a single utility class—ZosFilesHeaders—and replacing duplicate header creation code across multiple methods.

The new implementation leverages a unified headerMap to manage header generation functions, ensuring that headers like responseTimeout, etag, and others are applied consistently in all ZosFiles REST calls.

• Header Generation now:

  • depends on:
    • the request options
  • optionally takes:
    • dataLength parameter to add a Content-Length header when needed.
    • An enum (ZosFilesContext) that guides which Content-Type headers are applied for certain methods. The enum values include::
      • USS_MULTIPLE: Forces a general content-type header ("Content-Type": "application/json") when multiple USS files.
      • ZFS& LIST: No content-type headers are applied.
      • UPLOAD: Applies the content-type header ("X-IBM-Data-Type": encoding ). And will pass Content-Type: application/octet-stream for binary data.
      • DOWNLOAD: applies Content-Type header.
      • Default (no context): applies the default content-type header: {"X-IBM-Data-Type": "text"}

  ZosFilesHeaders.generateHeaders<T>({
    options,
    context,
    dataLength,
  }: {
    options: T;
    context?: ZosFilesContext;
    dataLength?: number | string;
  }): IHeaderContent[]

Because of this centralization, organization, and newly provided clear definitions for expected headers, any future header changes or additions require modifications in only one location. Creating headers can now be done with a single function call, without much thought required in future development of the methods within ZosFiles SDK.