API change for 8010464: Evolve java networking same origin policy

[Michael McMahon]

Another possibility if we were to do that in the future, could be:

"GET,POST:Header1=value 1,Header2=value 2"

- Michael

On 01/05/13 12:38, Dmitry Samersoff wrote:
> Michael,
>
> Sorry for not being clean enough.
>
> On my opinion an ability to check header value as well as a header name
> is quite useful future for the real world.
>
> e.g. to being able to prevent redirection to other domain or limit
> certain content type etc.
>
> I understand, that these changes is out of scope of today work, but it
> quite possible that we implement it sometimes in a future.
>
> For (header-name: header-value) pair  : (colon) is a native delimiter,
> so it's better not to use it to separate methods list and headers list.
>
> On my opinion, (space) is enough for this case and better reflect HTTP
> header i.e.
>
> "GET,POST Header1,Header2"
>
> -Dmitry
>
>
>
> On 2013-05-01 15:16, Michael McMahon wrote:
>> 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.
>