Hi Michael
492 boolean implies(Authority other) {
493 return userinfo.equals(other.userinfo) &&
494impliesHostrange(other) && impliesPortrange(other);
495 }
This means http://example.com does not imply http://some...@example.com.
Is this inten
Max,
Thanks for reviewing.
On 02/12/13 08:29, Weijun Wang wrote:
Hi Michael
492 boolean implies(Authority other) {
493 return userinfo.equals(other.userinfo) &&
494impliesHostrange(other) &&
impliesPortrange(other);
495 }
This means http:/
On 29/11/13 20:38, Alan Bateman wrote:
On 29/11/2013 18:03, Michael McMahon wrote:
This is another regression in JDK 8. A new "connecting" flag is
getting confused
when a redirect occurs and a POST gets converted to a GET.
http://cr.openjdk.java.net/~michaelm/8029127/webrev.1/
The change look
Is it possible to just ignore the userinfo part? I wonder if people will
complain why "user:pass" is not the same as "user".
--Max
On 12/2/13, 18:00, Michael McMahon wrote:
This means http://example.com does not imply
http://some...@example.com. Is this intended?
http://cr.openjdk.java.net/
It looks like userinfo is not permitted in http URLs anyway (in rfc
2616). And even if clients
are permissive about allowing it, any userinfo would most likely not be
seen by a server
since the request URI only contains the path component of the original URI.
I need to look at the bug report, t
On 12/2/13, 19:00, Michael McMahon wrote:
It looks like userinfo is not permitted in http URLs anyway (in rfc
2616). And even if clients
are permissive about allowing it, any userinfo would most likely not be
seen by a server
since the request URI only contains the path component of the origina
Okay. I think the best approach is to recognise the userinfo but just
remove it when constructing
URLPermissions thereby effectively ignoring it.
This is what the http protocol handler (and other support classes) have
been doing all the time
since the field is not directly of interest to http i
On 02/12/13 12:17, Weijun Wang wrote:
On 12/2/13, 19:00, Michael McMahon wrote:
It looks like userinfo is not permitted in http URLs anyway (in rfc
2616). And even if clients
are permissive about allowing it, any userinfo would most likely not be
seen by a server
since the request URI only con
Hi
based on feedback the changes for issue:
https://bugs.openjdk.java.net/browse/JDK-8025211
have been amended to the following:
http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/
please oblige and review
regards
Mark
On 29/11/2013 17:17, Mark Sheppard wrote:
Alan, Daniel,
thanks
On 02/12/2013 12:22, Michael McMahon wrote:
Okay. I think the best approach is to recognise the userinfo but just
remove it when constructing
URLPermissions thereby effectively ignoring it.
This is what the http protocol handler (and other support classes)
have been doing all the time
since th
Hi Mark,
This is much simpler indeed.
Thumbs up from me :-)
best regards,
-- daniel
On 12/2/13 1:35 PM, Mark Sheppard wrote:
Hi
based on feedback the changes for issue:
https://bugs.openjdk.java.net/browse/JDK-8025211
have been amended to the following:
http://cr.openjdk.java.net/~mshepp
Looks good to me Mark.
-Chris.
On 02/12/13 12:35, Mark Sheppard wrote:
Hi
based on feedback the changes for issue:
https://bugs.openjdk.java.net/browse/JDK-8025211
have been amended to the following:
http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/
please oblige and review
regards
Changeset: 4ca1027a130a
Author:vinnie
Date: 2013-12-02 14:19 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ca1027a130a
8029369: Shell tests in sun/security/pkcs11/ do not compile PKCS11Test
Reviewed-by: mullan
! test/sun/security/pkcs11/KeyStore/Basic.sh
! test/sun/securit
On 02/12/13 12:40, Alan Bateman wrote:
On 02/12/2013 12:22, Michael McMahon wrote:
Okay. I think the best approach is to recognise the userinfo but just
remove it when constructing
URLPermissions thereby effectively ignoring it.
This is what the http protocol handler (and other support classes
Changeset: 39b3b0e77af5
Author:msheppar
Date: 2013-12-02 14:01 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b3b0e77af5
8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java
Summary: modified test to execute in a single thread to eliminate potent
This update looks much better to me.
-Chris.
On 02/12/13 14:33, Michael McMahon wrote:
On 02/12/13 12:40, Alan Bateman wrote:
On 02/12/2013 12:22, Michael McMahon wrote:
Okay. I think the best approach is to recognise the userinfo but just
remove it when constructing
URLPermissions thereby ef
On 02/12/2013 14:33, Michael McMahon wrote:
The second webrev is at link below. This is somewhat simpler now.
I think it still needs a spec change though. So, I would like to propose
that to the CCC asap.
http://cr.openjdk.java.net/~michaelm/8029354/webrev.2/
I added a test that uses the prot
On 02/12/13 15:21, Alan Bateman wrote:
On 02/12/2013 14:33, Michael McMahon wrote:
The second webrev is at link below. This is somewhat simpler now.
I think it still needs a spec change though. So, I would like to propose
that to the CCC asap.
http://cr.openjdk.java.net/~michaelm/8029354/webr
Changeset: 5b5ee2288306
Author:naoto
Date: 2013-12-02 11:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b5ee2288306
8028368: There is no description whether or not java.util.ResourceBundle is
thread-safe
Reviewed-by: okutsu
! src/share/classes/java/util/ListResourceBund
Changeset: bcf5fa5e9509
Author:lancea
Date: 2013-12-02 16:06 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcf5fa5e9509
8029417: JDBC 4.2 javadoc updates
Reviewed-by: darcy
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/DriverManager.java
!
20 matches
Mail list logo
