Re: ​[discuss] Allow 200 responses for HEAD requests in REST API

Hey folks, Thanks for the feedback on the proposal. I believe it’s best to retain the current 204 response code for HEAD requests in the REST API. Existing client and server implementations that adhere to the spec expect only 204 responses. Introducing an additional 200 response code would create

Re: ​[discuss] Allow 200 responses for HEAD requests in REST API

Hi, >From my initial understanding of HTTP semantics, the HEAD request should be >treated like a GET request without a response body. Therefore, returning a 204 >for a HEAD request does not align with the concept held by most developers. I >support the idea of allowing a 200 response instead.

Re: ​[discuss] Allow 200 responses for HEAD requests in REST API

Hey Kevin, I also agree with Yufei. For PyIceberg we had a long list of issues around the head request (#1363 gives a nice overview) to check if the table is there (and that also has just been added to Java

Re: ​[discuss] Allow 200 responses for HEAD requests in REST API

I agree with Yufei's observation. Changing the return code in the spec from 204 to 200 will just cause additional downstream work that doesn't seem worth it. Returning 204 makes the API also very explicit in telling that the request succeeded but that there's no content in the response that the cli

Re: ​[discuss] Allow 200 responses for HEAD requests in REST API

The distinction between 200 and 204 is subtle enough that I'm comfortable using them interchangeably in this context. My main concern is that, if we make this change, all clients—except for PyIceberg—will need to be updated to support both 200 and 204, since a server could return either status code

​[discuss] Allow 200 responses for HEAD requests in REST API

Hey folks, I’d like to propose adding status code 200 as a valid response for HEAD requests in the Catalog REST API. Currently, the following HEAD requests return status code 204 for a successful response: * namespaceExists