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?
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.
So I'm wondering if it's better to allow users to inject their own header.
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?