Hey Sung, My interpretation is that it's up to the REST Server to decide whether to send a 419 or 401 response code (I don't think it's a mandate).
The use case for 419 would be that the client has client credentials or can re-authenticate via some other mechanism and could reattempt the request. This may be more useful with other auth mechanisms (e.g. SigV4), but that's not currently part of the reference implementation. So, I don't think it's necessary to remove 419 as the REST Catalog is not OAuth specific, but I think it's entirely reasonable (and likely correct based on the OAuth RFC) to respond with a 401 when using OAuth. -Dan On Wed, Feb 19, 2025 at 7:06 PM Sung Yun <sungwy...@gmail.com> wrote: > Hi folks, > > While working with the Polaris community on an issue[1], I decided to > bring this discussion to the Iceberg community mailing list as I > believe that the status code 419 in the REST Catalog Open API Spec may > have become a source of confusion for the community. > > In the Iceberg REST Catalog Open API Spec[2], 419 status code is > reserved for AuthenticationTimeoutResponse, which according to the > description means: > > "Credentials have timed out. If possible, the client should refresh > credentials and retry." > > I believe this description can be interpreted to mean that the 419 > status code should be reserved by the Iceberg REST Catalog for > responding to requests with expired tokens. I think it is important to > note that this is contrary to the recommended practice in RFC6750[3] > which mentions that the resource should respond with a 401 if the > access token is expired. This interpretation of the spec has already > resulted in PyIceberg introducing retries with token refreshes on 419 > status code[4]. > > So I'd like to ask the community - does the Open API Spec mandate that > a REST Catalog Server respond with a 419 status code on token > expiration? If not, would it make sense to remove the 419 status code > response from the spec, and instead make a recommendation on using 401 > for token expiration with a specific error message? > > In my opinion, having a consistent way of communicating to our clients > the rationale for denial of access is good practice, because it > informs the client on the next logical course of action they could > take. > > [1] https://github.com/apache/polaris/issues/791 > [2] > https://github.com/apache/iceberg/blob/6c546fe1346e81ca0c3f477695340016da891204/open-api/rest-catalog-open-api.yaml#L4571-L4584 > [3] https://www.rfc-editor.org/rfc/rfc6750 > [4] > https://github.com/apache/iceberg-python/blob/d1fea5c2bdd4cec248c20c0af51cf6c49966b7dd/pyiceberg/catalog/rest.py#L151-L156 >
