freesinger commented on PR #10818:
URL: https://github.com/apache/gravitino/pull/10818#issuecomment-4301648185
Thanks for raising this concern. I agree that changing the server-side
error response format is not something we should do casually.
Just to clarify, this PR does not change the wire format of Gravitino
server responses. The normal path is unchanged: if the server returns a valid
JSON ErrorResponse, the client still parses and handles it exactly as before.
What this PR changes is only the client-side fallback path for 401/403
when the response body is empty, missing, or not JSON. In those cases, the Java
client currently loses the HTTP semantics and throws a generic RESTException.
This patch preserves the
unauthorized/forbidden semantics by mapping those malformed responses to
UnauthorizedException / ForbiddenException based on the HTTP status.
The reason I handled it on the client side is that these 401/403 responses
may come from components outside Gravitino itself, such as an auth gateway,
reverse proxy, or servlet filter, where we cannot guarantee a formatted
ErrorResponse body.
So to be explicit: this PR is not proposing a common practice of changing
the error response format. It is a compatibility/robustness fix in the client
for non-standard error bodies, while keeping the existing JSON ErrorResponse
path unchanged.
If the community prefers, I’m also happy to follow up separately on the
server side to normalize Gravitino-generated 401/403 responses. But I think the
client-side fallback is still needed for external gateway/filter cases.
--
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]