Yeah, I don't think that this response was used. We thought that it was
needed but it can probably be safely removed as I'm not aware of any
implementation that sent or handled it. If that's the right thing to do
because there are other more standard mechanisms for sending more
information about a
Hi all,
Thanks Sung for your support – I will start a discussion thread soon on the
topic of expected client behavior for both 401 and 419 response codes.
And out of curiosity, I looked at how the AuthenticationTimeoutResponse
type was currently handled in iceberg-core, and was surprised to see t
Thank you Daniel, Dmitri, Alex and Yufei for sharing your thoughts.
I'm in favor of updating the REST Spec to be more clear about these
status codes.
Here's a PR[1] that follows the RFC language to make expected and
recommended behaviors of the server and the client more explicit
(thanks Dmitri f
I'm fine with 419 being considered an optional status code, in which case:
1. Servers can choose not to implement it.
2. Clients shouldn't rely solely on it for token expiration.
However, the current REST spec doesn't clarify this. We should make it more
explicit.
We could try to deprecate
Hi all,
I think there are two aspects in this issue that should be discussed
separately:
1. What are the pros and cons of having a custom HTTP response code for
authentication issues, as opposed to using 401?
2. How should clients deal with authentication issues, both 401 and 419?
*Rega
Thank you for your response, Dan! I agree with all your points.
On the other hand, I guess readers of the Catalog REST API spec may still
be uncertain about when specific error codes MAY or SHOULD occur (using the
traditional RFC language).
Do you think it might be worth clarifying the REST spec
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.
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
