AW: [Patch] 6502392 Invalid relative names for Filer.createResource and Filer.getResource

[Jonathan Gibbons]

Emil,

First, some updates.
1) 6791041 has come in, which reports a specific instance of a user  
encountering the issue you have been looking at. Specifically,
the submitter is affected by the "quick and dirty" check in  
isRelativeURI.
2) I have filed 6791060 against java.net.URI

It sounds like you are reasonably familiar with the RFCs involved  
here. If so, can you briefly summarize any relevant differences
between RFC 2396 (used by java.net.URI) and RFC 3986 (used by JSR 269  
and Filer.)

-- Jon

On Jan 6, 2009, at 8:21 AM, Emil Siemes wrote:

> Hi Jon,
>
> true, the code actually does things which would belong into  
> java.net.URI. Reason for this is that JSR269 requires compliance  
> with path-rootless rule of RFC3986 whereas java.net.URI supports the  
> older and obsolete RFC 2396. Basically I was afraid of relying on  
> the old implementation but that can be changed of course.
> Given the limitation of the actual URI implementation it might be  
> tricky to achieve compliance with the JSR269 requirements without  
> parsing URI.getPath(). Dot-segments are not allowed as relative path  
> names in JSR269 but are fine for the URI class. The current  
> implementation calls URI.normalize().getPath() which actually  
> removes dot-segments and therefore doesn't throw an exception.
>
> Given your feedback I propose I rewrite my code in a way that it  
> relies on java.net.URI and does a quick check on the path. May be I  
> can compare URI.getPath() and URI.normalize().getPath() to find out  
> if any dot-segments are part of the path. I'll check and let you know.
>
> Thanks
>    Emil
>
>
>
>
>
> Von: Jonathan Gibbons <Jonathan.Gibbons at Sun.COM>
> An: Emil Andreas Siemes <digitalemil at yahoo.de>
> CC: compiler-dev at openjdk.java.net
> Gesendet: Dienstag, den 6. Januar 2009, 02:11:22 Uhr
> Betreff: Re: [Patch] 6502392 Invalid relative names for  
> Filer.createResource and Filer.getResource
>
> Emil,
>
> Thank you for looking at this, and for your patch.
>
> I do not understand why 6419701 is not public. I am trying to find  
> out why it is not.
> The bug itself is about the use of URI.create, not about the use of  
> isRelativeURI..
>
> I'm not sure that your patch is warranted (or arguably, the correct  
> fix).  Your patch certainly
> contains functionality that on the face of it would better belong in  
> java.net.URI and not
> JavacFileManager.
>
> The way I read the code in JavacFileManager, isRelativeURI is not  
> intended to be a full and
> complete implementation of checking whether a URI is path-rootless.  
> Instead, it is used in
> exactly 3 places, and always in conjunction with URI.create.   
> JavacFileManager is assuming
> the full syntax checking is done by URI.create, and is just using a  
> simple impl of
> isRelativeURI to distinguish relative URIs from absolute URIs  
> created by URI.create.
>
> 6419701 is about removing the use of URI.create -- presumably  
> because it is mildly icky
> to create the URI object just to check whether a path string is a  
> valid URI.  So it seems
> to me that there are two ways to take this issue:
> 1) Rewrite isRelativeURI to take a String argument and thereby avoid  
> the use of URI.create
> 2) Wait for URI to have some better method for checking the validity  
> of a path without
> actually constructing the URI object.
>
> I guess that I dislike JavacFileManager having code for detailed  
> parsing of URIs, and so
> I think the current impl is better, of using URI.create to check the  
> syntax of a URI, and
> then apply a quick check as to whether it is absolute or relative is  
> better.
>
> Or am I misreading the situation or perhaps missing some subtlety in  
> your proposed code?
>
> -- Jon
>
>
> Emil Andreas Siemes wrote:
>>
>> com.sun.tools.javac.file.JavacFileManager checks if a name fulfills  
>> the requirements of relative names:
>> "A relative name is a non-null, non-empty sequence of path segments  
>> separated by '/'; '.' and '..' are invalid path segments. A valid  
>> relative name must match the "path-rootless" rule of RFC 3986,  
>> section 3.3."
>>
>> This is done via the isRelativeUri() method. Unfortunately this  
>> method doesn't currently really check for path-rootless compliance.  
>> A patch with an improved method is attached.
>> When java.net.Uri eventually supports RFC 3986 the need for  
>> isRelativeUri() goes away. I would also like to propose to rename  
>> isRelativeUri() to isRF3986PathRootless() which would more clearly  
>> describe what the method does.
>>
>> There is a comment in JavacFileManager in a couple of lines:
>> //FIX ME 6419701
>> but I don't find bug 6419701 in the bug database. Any thoughts?
>>
>> Thanks
>>     Emil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20090107/238d7cf5/attachment.html