-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XML deserializate failed when text contains &()_+-=;
#719
Comments
In the mentioned case should be possible to keep unrecognized entities unexpanded. We have However, I assume, that entity |
Yep. This file path was randomly selected for testing purposes to ensure the storage services can handle special characters correctly. |
Our current workaround involves manually escaping the special string before deserialization. Do you think that's a good idea? let s = s.replace("&()_+-=;", "%26%28%29_%2B-%3D%3B"); However, I suspect we'll still encounter issues like |
Are you provide the path with special characters to JFrog API and it forms such XML or that XML was constructed directly? I'm very doubt that such mature project doesn't know how to correctly escape In the example of the provided response you can notice that it is actually contains
I doubt that response will contain path partially encoded, seems more like hand-crafted data. Your workaround in any case is not correct, because it replaces exactly the string |
Yes. We write a file with path The response is neither created nor altered by us. The code could be found at here let req = req
.body(AsyncBody::Bytes(Bytes::from(PROPFIND_REQUEST)))
.map_err(new_request_build_error)?;
// --------- send request to jfrog
let resp = self.client.send(req).await?;
if !resp.status().is_success() {
return Err(parse_error(resp).await?);
}
// ---------- read the body and concat into a `Bytes`
let bs = resp.into_body().bytes().await?;
// ---------- deserialize it with quick-xml
let result: Multistatus = deserialize_multistatus(&bs)?; Sorry for let you jumping into our code.
You're correct. Is it safe to ignore unrecognized XML entities? Like keep all |
Then you should create a bug report in JFrog. If the returned path is guaranteed to be the one that you provided in request (but normalized) then you could sanitize the input.
This depends on your needs. |
Hi, I'm from Apache OpenDAL Community. I found an interesting cases that
quick-xml
failed to deserializate content like&()_+-=;
.Context
We are developing WebDAV support with JFrog Artifactory. I'm not sure how JFrog implements WebDAV support, but it seems they do not correctly escape the XML content.
We found that jfrog will return invalid content like
quick-xml
will recongize&()_+-=;
as an XML entity thus lead to deserializate failure:To Reproduce
deserializate content like
into
Related Issues
I understand this seems more like an issue for jfrog to address, but I believe it's also valuable to inform the quick-xml maintainer about this situation.
The text was updated successfully, but these errors were encountered: