API change for 8010464: Evolve java networking same origin policy

[Kurchi Hazra]

Hi Michael,

      From the documentation, it is not clear to me how to represent 
both request-headers and method list together in an actions string for 
two or more methods. (Say I have two methods GET and POST and I want
to specify a request-headers list for each, how do I do it?) Maybe 
another example will help.

Thanks,
Kurchi

On 4/29/2013 3:53 AM, Michael McMahon wrote:
> 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.
>

-- 
-Kurchi