API change for 8010464: Evolve java networking same origin policy

[Dmitry Samersoff]

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

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