Skip to content

new feature: allow users to inject customized HTTP header #7894

Description

@dentiny

Feature Description

Hi team, there're a lot of storage backends which declare themself to be S3 compatible, but they have slight differences.
One concrete example is #7821, netapp S3 compatible object storage requires content-length in copy request, otherwise the request will get rejected.

OpenDAL, from my perspective, should focus on the well-documented S3 spec, instead of adding undocumented logic for different vendor impls.

  • Each vendors' implementation could conflict with each other
  • Support different types of S3 backend in OpenDAL core increases maintenance overhead
    • For example, netapp S3 API is not open source, with undocumented request format, no docker image provided, I don't even know how can we test and maintain

So I'm wondering if it's better to allow users to inject their own header.

  • User-side should have little overhead to maintain a small list of headers
  • Vendors could have their customized headers for performance (the object storage I'm working does so)

This feature request is not specific to S3 backend, but should be general enough for all backends.

Problem and Solution

For all the operator APIs, we allow users to inject their own headers, which will be propagated to HTTP requests.

Additional Context

See original PR and thread for details at #7884 (comment)

Are you willing to contribute to the development of this feature?

  • Yes, I am willing to contribute to the development of this feature.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestreleases-note/featThe PR implements a new feature or has a title that begins with "feat"services/http

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions