API change for 8010464: Evolve java networking same origin policy

[Dmitry Samersoff]

Michael,

I'm just asking about replacing : (colon) to another character to be
able to write something like:

 permission
 java.net.HttpURLPermission "http://www.foo.com/-",
 "GET Location: http://www.foo.com/*, Content-type: image/jpeg";

in a future

-Dmitry.

On 2013-05-01 15:04, Michael McMahon wrote:
> On 01/05/13 11:09, Dmitry Samersoff wrote:
>> Michael,
>>
>>> "GET,POST:Header1,Header2"
>> Colon is a delimiter between http header and it's value.
>>
>> With this syntax we might have problems in a future if sometimes we will
>> support different headers for different methods or add an ability to
>> check header value as well.
>>
>> -Dmitry
> 
> Dmitry,
> 
> It would complicate the syntax a lot if you wanted to support
> different headers for different methods. Would be a lot simpler
> to just grant separate permissions for the two cases. Eg.
> 
> grant {
>     permission  java.net.HttpURLPermission "http://www.foo.com/-",
> "GET:Header1,Header2";
>     permission  java.net.HttpURLPermission "http://www.foo.com/-",
> "POST:Header3,Header4";
> };
> 
> Michael
> 
>> On 2013-04-30 14:30, Michael McMahon wrote:
>>> Hi Kurchi,
>>>
>>> I can include such an example easily. Eg:
>>>
>>> "GET,POST:Header1,Header2"
>>>
>>> means one permission that permits either GET or POST with either or both
>>> of the two headers. If you wanted to restrict one set of headers to GET
>>> and another set to POST, then that would require two different
>>> permissions.
>>>
>>> - Michael
>>>
>>> On 30/04/13 00:40, Kurchi Hazra wrote:
>>>> 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.
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer