moomindani opened a new pull request, #17979:
URL: https://github.com/apache/iceberg/pull/17979

   Closes #17978.
   
   Freshness-aware table loading did nothing at all when the catalog server 
wrote the `ETag` response header in any spelling other than `ETag`. 
`HTTPClient` collected response headers into a map keyed by the name exactly as 
received, `RESTSessionCatalog` copied that into another `HashMap` and read the 
tag back as `HttpHeaders.ETAG`, so a server that sent `etag` left `tableCache` 
empty. No later load sent `If-None-Match`, and nothing surfaced the fact that 
the server had answered with a tag.
   
   Header field names are case-insensitive (RFC 9110 section 5.1), and 
lowercase is mandatory in HTTP/2 (RFC 9113 section 8.2.1), so a client cannot 
key on the spelling a server happened to choose. Both maps are now 
case-insensitive, which fixes the lookup without changing what callers see 
otherwise.
   
   I hit this against an Armeria-based catalog server, which writes HTTP/1 
header names in their lowercase HTTP/2 form by default: the server returned a 
correct `ETag` for a conditional `loadTable` and the client could not see it. 
The same applies to any server reached over HTTP/2.
   
   Tests:
   
   - `TestHTTPClient.responseHeadersAreReadWithoutRegardToCase` has the mock 
server answer with `etag` and asserts the map handed to the caller resolves 
both spellings, covering the collection point.
   - `TestFreshnessAwareLoading.freshnessAwareLoadingWithLowercaseETagHeader` 
drives a catalog through an adapter that reports its response headers 
lowercased, and asserts the table cache is still populated and the second load 
is answered from it, covering the consumer.
   - Both fail on an unfixed tree. `./gradlew :iceberg-core:test --tests 
"org.apache.iceberg.rest.*"` passes.
   


-- 
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]

Reply via email to