dentiny opened a new issue, #7894: URL: https://github.com/apache/opendal/issues/7894
### Feature Description Hi team, in production, there're a lot of storage backends which declare themself to be S3 compatible, but they have slight differences. One concrete example is https://github.com/apache/opendal/issues/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 headers for different vendor impls. - Each vendors' implementation could conflict with each other - Support different types of S3 backend in OpenDAL core increases maintenance overhead 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 https://github.com/apache/opendal/pull/7884#issuecomment-4926332061 ### Are you willing to contribute to the development of this feature? - [x] Yes, I am willing to contribute to the development of this feature. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
