hg: jdk8/tl/jdk: 6594296: NetworkInterface.getHardwareAddress returns zero length byte array
Changeset: 17cf61ff Author:chegar Date: 2013-05-01 10:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17cf61ff 6594296: NetworkInterface.getHardwareAddress returns zero length byte array Reviewed-by: alanb ! src/windows/native/java/net/NetworkInterface_winXP.c ! test/java/net/NetworkInterface/Test.java
Re: API change for 8010464: Evolve java networking same origin policy
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
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 73793f2af80a Author:msheppar Date: 2013-04-30 16:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/73793f2af80a 8007799: Base64.getEncoder(0, byte[]) returns an encoder that unexpectedly inserts line separators Reviewed-by: sherman, iris ! src/share/classes/java/util/Base64.java + test/java/util/Base64/Base64GetEncoderTest.java Changeset: 5941f7c9c76a Author:chegar Date: 2013-05-01 11:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5941f7c9c76a 8013723: ProblemList.txt updates (5/2013) Reviewed-by: alanb ! test/ProblemList.txt
Re: API change for 8010464: Evolve java networking same origin policy
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.
Re: API change for 8010464: Evolve java networking same origin policy
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 prot
Re: API change for 8010464: Evolve java networking same origin policy
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:
Re: API change for 8010464: Evolve java networking same origin policy
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()
Re: API change for 8010464: Evolve java networking same origin policy
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.
T
Re: API change for 8010464: Evolve java networking same origin policy
Michael,
On 2013-05-01 16:40, Michael McMahon wrote:
> Another possibility if we were to do that in the future, could be:
>
> "GET,POST:Header1=value 1,Header2=value 2"
Variant with space looks more natural for me as it follows HTTP header
syntax.
But it's up to you to make a decision.
-Dmitry
>
> - 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 inter
hg: jdk8/tl/jdk: 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt
Changeset: ae4a82e69da2 Author:weijun Date: 2013-05-01 21:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ae4a82e69da2 8012082: SASL: auth-conf negotiated, but unencrypted data is accepted, reset to unencrypt Reviewed-by: vinnie ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java + test/sun/security/krb5/auto/SaslGSS.java
hg: jdk8/tl/jdk: 8012665: add CharSequence.chars, CharSequence.codePoints
Changeset: c6aef650e615 Author:mduigou Date: 2013-05-01 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6aef650e615 8012665: add CharSequence.chars, CharSequence.codePoints Reviewed-by: martin, alanb, ulfzibis, mduigou Contributed-by: Stuart Marks , Henry Jen ! src/share/classes/java/lang/CharSequence.java + test/java/lang/CharSequence/DefaultTest.java ! test/java/lang/StringBuffer/TestSynchronization.java
Code Review Request: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name
Hi, NetworkInterface.getByInetAddress() was crashing on solaris when the system had a network interface name longer than 15 characters, due to two instances in the native code for NetworkInterface where we were copying a char array of size 32 (LIFNAMSIZ) into a char array of size 16 (IFNAMSIZ), resulting in a buffer overflow with long names. The fix is to make sure that the space allocated for the interface name is consistent (16/32 bytes depending on the system), and to prevent overflows by using strncpy instead of strcpy. Bug: http://bugs.sun.com/view_bug.do?bug_id=8013140 Webrev: http://cr.openjdk.java.net/~khazra/8013140/webrev.00/ Thanks, - Kurchi
