API change for 8010464: Evolve java networking same origin policy
Dmitry Samersoff
dmitry.samersoff at oracle.com
Wed May 1 04:38:03 PDT 2013
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.
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
More information about the net-dev
mailing list