The decoding routine decodes %xx into the equivalent character. In the case of %2b, the resulting character is the plus sign (+). Separately, if the decoded or undecoded character is a plus sign, it is replaced with a space. I think that the space for plus replacement should not take place if a decoding just took place. In a modification we made, we replaced this: if (b == '+') { b = (byte)' '; } with this: else if (b == '+') { b = (byte)' '; } That way, the just-decoded plus sign won't be turned into a space, but a literal plus sign will be turned into a space. As far as I can tell, this is the correct behavior, and corrects a problem we were having storing files with plus signs in their file names in Slide repositories. We are using a modified version of SLIDE_2_1_M1_RELEASE on various platforms, but the code quoted above is still present in the most recent CVS versions.
In August 2004 Unico Hommes performed some refactoring of the org.apache.util package and moved classes to org.apache.slide.webdav.util. However, it seems that URLUtil.java was never deleted at the old location and in CVS HEAD there are now two versions. The older org.apache.util.URLUtil does indeed still have the bug you describe, but in the newer org.apache.slide.webdav.util.URLUtil it is fixed. I would suggest that org.apache.util.URLUtil is deleted from CVS (marked as Dead instead of Exp in HEAD). It is the only remaining class in the org.apache.util package and seems just forgotten. Path is src/util/org/apache/util/URLUtil.java
Strange nobody ever noticed this before. I've removed the file now. Thanks for reporting.
Fixed in the new org.apache.slide.webdav.util.URLUtil. Please migrate any integration code to this class and the '+' de-coding is no longer an issue.