API change for 8010464: Evolve java networking same origin policy

[Michael McMahon]

Ah right. The permission only contains header names.
It never contains header values. And header names are "tokens"
in the Http spec that cannot contain a colon character.

Michael

On 01/05/13 12:11, Dmitry Samersoff wrote:
> 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.
>