You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As already mentioned in #1007, the exception message in case of a server error is just a XmlSerializer error message, not the error information the server sent.
message: There is an error in XML document (2, 2). and
inner exception message <Error xmlns='http://s3.amazonaws.com/doc/2006-03-01/'> was not expected.
is raised. This gives no guidance to help spotting the cause of the problem.
Expectation
If a deserialization exception happens (error XML instead of success XML), try to deserialize the server provided error xml document with the right deserializer and pass this information on to the thrown exception.
Example error response
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><Key>TestPut.json</Key><BucketName>bucket</BucketName><Resource>/bucket/TestPut.json</Resource><RequestId>17B3FBA079802363</RequestId><HostId>dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8</HostId></Error>
It would be nice if errors would generally get handled better.
E.g. if you execute a GetObjectAsync(...) call and the server responds with something like
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AuthorizationHeaderMalformed</Code><Message>The authorization header is malformed; the region is wrong; expecting 'SOMETHING'.</Message><Key>812f9d5c-d8ba-413b-b23b-4b02dcfe9723</Key><BucketName>dummy</BucketName><Resource>dummy/812f9d5c-d8ba-413b-b23b-4b02dcfe9723</Resource><Region>SOMETHING</Region><RequestId>asdf...</RequestId><HostId>asdf...</HostId></Error>
but the Exception is something like this: Minio.Exceptions.InvalidObjectNameException: MinIO API responded with message=Invalid object name..
This makes it very hard to track down the original issue.
I think the reason of the issue is that before each request the library executes an "HEAD" request - and those requests doesn't have any response body the SDK can use to parse the cause of the error. Why does the SDK even send a "HEAD" request before each other request? Isn't this pretty inefficient?
As already mentioned in #1007, the exception message in case of a server error is just a
XmlSerializer
error message, not the error information the server sent.Steps To Reproduce
Please follow the steps outlined in #1007
Currently, an
InvalidOperationException
withThere is an error in XML document (2, 2).
and<Error xmlns='http://s3.amazonaws.com/doc/2006-03-01/'> was not expected.
is raised. This gives no guidance to help spotting the cause of the problem.
Expectation
If a deserialization exception happens (error XML instead of success XML), try to deserialize the server provided error xml document with the right deserializer and pass this information on to the thrown exception.
Example error response
Info
MinIO (NuGet): 6.0.2
MinIO (Server): 2024-02-06T21:36:22Z
The text was updated successfully, but these errors were encountered: