micolous commented on issue #49: URL: https://github.com/apache/arrow-rs-object-store/issues/49#issuecomment-2741840837
> We COULD make `object_store` more friendly (move it from uncommon to common behavior within the spec), but ultimately it's nginx that has to fix their stuff. While nginx *could* allow clients to send both headers, this wouldn't *completely* fix the problem. As I noted previously, [for AWSv4 signed requests, the data being signed differs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv-create-signed-request.html#create-canonical-request) depending on whether it is sent over HTTP/1.1 (`Host` header only) or HTTP/2 (`:authority` header and maybe *also* `Host` header). As such, a client always needs to know whether its request will be sent over HTTP/1.1 or HTTP/2 ahead of time. ALPN may give clues here (if the server has configured it), but it's then a question of whether your HTTP library allows `arrow-rs` to learn which version is used immediately before the request is actually sent. A simpler alternative is that `arrow-rs` could be configured to send requests exclusively using one version of HTTP that is chosen ahead of time by the library developer (or a configuration option available in their application). The downside is that if a service starts providing HTTP/2, clients will need to update their configuration to take advantage of it. This is an issue for *anything* sending AWSv4 signed requests, not just S3-compatible object storage services. > So if a HTTP/2 proxy has a HTTP/1.1 upstream does it not convert the pseudo header (`:authority:`) into its HTTP/1.1 counterpart (`Host`)? That seems like an oversight in the spec. [This is covered in the spec](https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.3): > An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a `Host` header field if one is not present in a request by copying the value of the ":authority" pseudo-header field. and: > To ensure that the HTTP/1.1 request line can be reproduced accurately, \[\[the `:authority`\]\] pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in origin or asterisk form (see [[RFC7230], Section 5.3](https://datatracker.ietf.org/doc/html/rfc7230#section-5.3)). As "origin form" includes an `:authority` header like `storage.cloud.example.com`, a HTTP/2 to HTTP/1.1 proxy would drop the `:authority` header for such requests. However, as these headers are included in AWSv4 signing, a HTTP/1.1 upstream implementing AWSv4 signing would need to know that the request was originally sent with HTTP/2 **and** whether it originally included a `Host` header (as it may have been copied from `:authority`, but must not *differ* when *both* are provided) in order to reproduce the client's request signing process accurately. -- 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]
