API change for 8010464: Evolve java networking same origin policy

[Michael McMahon]

On 28/04/13 09:01, Chris Hegarty wrote:
> In the main I link the new HttpURLPermission class.
>
> When reading the docs I found the references to "the URL" and "URL 
> string" confusing ( it could be just me ). When I see capital 'URL' my 
> mind instantly, and incorrectly, goes to java.net.URL. In all cases 
> you mean the URL string given when constructing the HttpURLPermission, 
> right?
>

Yes, that is what is meant. The class does not use j.n.URL at all, as 
that would bring us back
to the old (undesirable) behavior with DNS lookups required for basic 
operations like equals() and hashCode()

> Another example is the equals method
>   "Returns true if, this.getActions().equals(p.getActions()) and p's
>    URL equals this's URL. Returns false otherwise."
>
> this is referring so a simple string comparison of the given URL 
> string, right? This should be case insensitive too. Does it take into 
> account default protocol ports, e.g. http://foo.com/ equal 
> http://foo.com:80/
>

The implementation uses a java.net.URI internally. So URI takes care of 
that.

> implies() makes reference to the URL scheme, and other specific parts 
> of the URL. Also, the constructors throw IAE  'if url is not a valid 
> URL', but what does this mean. Should we just bite the bullet and just 
> say that URI is used to parse the given string into its specific 
> parts? Otherwise, how can this be validated.
>

I originally didn't want to mention URI in the apidoc due to potential 
confusion surrounding the use of URL in the permission
class name. But, maybe it would be clearer to be explicit about it, 
particularly for the equals() behavior.
Otherwise we have to specify all of it in this class.

> As for the additions to HttpURLConnection, what are the implications 
> on proxies? Permissions, etc...
>

There's no change in behavior with respect to proxies. Permission is 
given to connect to proxies implicitly
except in cases where the caller specifies the proxy through the 
URL.openConnection(Proxy) api.
There are other unusual cases like the Http "Use Proxy" response. 
Explicit permission is required
for that case also.

Thanks!

Michael

> -Chris.
>
> On 04/26/2013 03:36 PM, Michael McMahon wrote:
>> Hi,
>>
>> The is the suggested API for one of the two new JEPs recently submitted.
>>
>> This is for JEP 184: HTTP URL Permissions
>>
>> The idea here is to define a higher level http permission class
>> which "knows about" URLs, HTTP request methods and headers.
>> So, it is no longer necessary to grant blanket permission for any kind
>> of TCP connection to a host/port. Instead a HttpURLPermission restricts
>> access to only the Http protocol itself. Restrictions can also be 
>> imposed
>> based on URL paths, specific request methods and request headers.
>>
>> The API change can be seen at the URL below:
>>
>> http://cr.openjdk.java.net/~michaelm/8010464/api/
>>
>> In addition to defining a new permission class, HttpURLConnection
>> is modified to make use of it and the documentation change describing 
>> this
>> can be seen at the link below:
>>
>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html
>>
>> All comments welcome.
>>
>> Thanks
>>
>> Michael.