Illegal character in path at index X list(String path, Integer deph)

[OBounif]

First and foremost, I'd like to extend my sincere appreciation to the library contributor for their invaluable contribution and for providing us with such a helpful library. Your work has been instrumental in many ways, and it's greatly appreciated.

I'm experiencing a weird behavior related to the list method, specifically in situations where spaces are included in the input data. The root cause of this issue is the inability of the URI class to create an instance when it encounters spaces within the input. Consequently, this limitation is preventing the library from processing data that contains spaces effectively, leading to unexpected behavior or errors.

I don't know if that problem it is normal or not, I tried to encode data using URL encoder but it makes it worse :/.

NB :
The exception is thrown in the constructor of HttpPropFind class
public HttpPropFind(final String uri) { this(URI.create(uri)); }

[lookfirst]

Hi there,

Thanks for the recognition, much appreciated. This is more of a discussion than an issue, so I've migrated it.

I took the stance a very long time ago that the library shouldn't validate or mutate input and that was your role as a developer using the library. The reason is that it creates a lot of potential blackbox behavior.

So, if the URI has spaces in it, then you should be the one encoding the URI first. In fact, I'd argue you're passing in a String, not a URI, since URI's don't actually have spaces. =)

I don't know what you tried for encoding, but yea... you're going to have to pass something into URI.create() that doesn't cause it to throw exceptions.

Best!

[OBounif]

Thank you for your response. I completely understand the Idea behind not having the library validate or mutate input, and I agree that it helps maintain transparency and predictability.

I'd like to clarify that in my previous attempts, I've encrypted the path portion of the URL and it worked as expected. However, when I attempted to encrypt the entire URL, I encountered some challenges. It seems that ensuring proper encoding for the entire URL, including query parameters, might require a different approach or additional handling :)

Once again, thank you for your feedback.
Cordialement,

[lookfirst]

You are likely correct that you need to do some specialized parsing on your end. I'd compare the output of the two encoding methodologies to see how things are being borked and then work to resolve it from there.