Bugzilla – Full Text Bug Listing
| Summary: | URIUtil.makeRelative does not make relative if uri contains (escaped) brackets | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Missing name Missing name <luzifer42> | ||||||||
| Component: | Components | Assignee: | Thomas Watson <tjwatson> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | dj.houghton, john.arthorne, tjwatson | ||||||||
| Version: | unspecified | Flags: | john.arthorne:
review+
|
||||||||
| Target Milestone: | 3.7 M7 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
The problem seems to be happening because URI#getSchemeSpecificPart() is taking the encoded URI (C:/Folder/FileWithBrackets%5B%5D) and returning a decoded string (as it is spec'd to do). The calculation of the relative part is correct but later we are passing that string into the URI constructor and it is bailing because the brackets are invalid chars so it is just returning the original string. I have added your sample code below into a disabled test in the suites. (_testBug331314) Created attachment 194000 [details]
possible patch
I wonder if simply calling getRawSchemeSpecificPart is the fix? There seems to be other places where encoding is not considered.
For example, org.eclipse.core.runtime.URIUtil.fromString(String) javadoc states that the unencoded string will be encoded according to the URI specification, but I don't see that happening in the code.
Created attachment 194011 [details]
possible patch
Here is a better patch that uses the four part URI constructor. This may not handle fragment file: URIs correctly, but I am not sure the original code handled it at all.
DJ, could you review? Also give an opinion on if you think it is necessary to fix this in 3.7. I am thinking it is not that important and am leaning to deferring it. The fix looks good to me, and I think it's worth fixing.
It seems like inconsistent behaviour in URI. The three part URI constructor says it will encode any illegal characters for you, but it doesn't handle square brackets. Perhaps it interprets this as an IPv6 literal. In any case I can see that the four part URI constructor you are using will encode square brackets correctly.
The test case smells like something that might fail or act strangely on non-windows platforms. In other tests I've used a base path like this to ensure it does the right thing on all platforms:
File base = new File(System.getProperty("java.io.tmpdir"));
Created attachment 194192 [details]
Updated patch
This patch updates the testcase with John's suggestion. I think [] must be getting interpreted as an IPv6 since the three part constructor takes a single ssp which contains all components of the ssp in a single string. Where the other 4 and 5 part URI constructors split the host component out into a separate param which can treat [] as special.
I released the last patch with updated copyright date to be 2011. verified in I20110428-0848. |
Build Identifier: 20100917-0705 URIUtil.makeRelative does not make the uri relative if the URI contains (escaped) brackets. I dont know if it is only related to brackets, but it should work for any uri. Reproducible: Always Steps to Reproduce: File file1=new File("C:/Folder/FileWithBrackets[]"); URI f1=file1.toURI(); URI b1=file1.getParentFile().toURI(); URI r1=URIUtil.makeRelative(f1, b1); System.out.println(r1.isAbsolute()); File file2=new File("C:/Folder/FileWithoutBrackets"); URI f2=file2.toURI(); URI b2=file2.getParentFile().toURI(); URI r2=URIUtil.makeRelative(f2, b2); System.out.println(r2.isAbsolute());