adutra commented on PR #15171:
URL: https://github.com/apache/iceberg/pull/15171#issuecomment-3990554958
> the cache must first strip out all headers which haven't been signed,
which can be done using the SignedHeaders header or X-Amz-SignedHeaders query
param (if there are any cases where that is used).
I'm not sure this is going to work. I see how we could add entries to the
cache with just the signed headers; but how can we *read* the cache?
E.g. assume at T1 the cache contains:
```
key1 { PUT, https://example.com/path, signed headers = { k1=v1, k2=v2 } } =>
response1 { ... }
```
At T2, the following request arrives:
```
PUT https://example.com/path, headers = { k1=v1, k2=v2, k3=v3 }
```
Here I see two problems:
1. We cannot create a cache key directly from the incoming request; we'd
need to iterate over the cache entries, and do some sort of similarity search;
2. Assume we identify `key1` as a potential candidate for a cache hit:
still, is it OK to match the incoming request with `key1`? That can only be
known *after* the request has been signed, and will depend on whether `k3` has
been signed or not. If `k3` is a signed header, it would be incorrect to return
`response1` from the cache.
I'm not sure I'm very clear 😄
How about a pre-defined blocklist of headers that are known to never be
signed and that would always be excluded from the cache key? I see that you are
exploring this idea in #15428, so maybe that's the way to go?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
