ll)
bind(localAddr);
if (address != null)
connect(address);
} catch (IOException e) {
close();
throw e;
}
}
-Original Message-
From: Michael McMahon [mailto:michael.x.mcma...@oracle.com]
Sent:
On 08/09/11 21:40, Alan Bateman wrote:
Michael McMahon wrote:
Sigh. Hopefully this is the last webrev.
http://cr.openjdk.java.net/~michaelm/7085981/webrev.4/
Socket.java changed from last one. If there's no objection
I'll push this version.
- Michael.
DatagramSocket(SocketAddress)
Alan,
It didn't occur to me to use that new multi-catch construct.
I've actually just committed the previous version. But, I think
this is clearer so I'd like to make this change under a new CR.
- Michael.
On 09/09/11 14:08, Alan Bateman wrote:
Michael McMahon wrote:
Yes,
http://cr.openjdk.java.net/~michaelm/7088747/webrev.1/
There are no changes in the first two files, only Socket.java
- Michael.
On 09/09/11 14:08, Alan Bateman wrote:
Michael McMahon wrote:
Yes, the regression tests picked that up as well. Well spotted.
http://cr.openjdk.java.net/~michaelm
Hi,
Could I get the following code change reviewed please?
The problem is in AbstractPlainDatagramSocket.create(). If
ResourceManager.beforeUdpCreate()
throws an exception then fd is left set in the impl object. And if the
finalizer for this object
runs then it will attempt to close the object
My last changeset was missing the file for Windows XP, with the effect
the new test is failing on XP.
This is to address that problem
http://cr.openjdk.java.net/~michaelm/7091369/webrev.3/
Thanks
Michael
Could I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7079012/webrev.1/
We're getting an unexpected error in native code on Solaris when calling
the ioctl() that returns hardware MAC addresses for certain kinds of
NetworkInterface.
So, the fix is not to throw an
Looks fine. Possibly the comment
line at 102:AbstractPlainSocketImpl.java is not really
needed/appropriate though.
- Michael.
On 07/10/11 06:40, Chris Hegarty wrote:
Michael, Alan,
This is a follow up to CR 7073491 where the same issue was addressed
in DatagramSocket. This CR proposes to ad
Hi,
We have a few test failures on the nightly test run.
So, I'd like to move them on to the problem list pending
investigation.
http://cr.openjdk.java.net/~michaelm/7102665/webrev.1/
Thanks,
Michael
Chris,
Would you mind taking a look at this? It's a small change to the http
server.
http://cr.openjdk.java.net/~michaelm/7110484/webrev.1/
I haven't included a regression test because to test it reliably would
require
at least a minute's worth of test time. I'm not sure the issue warrants
t
On 10/11/11 13:31, Michael McMahon wrote:
Chris,
Would you mind taking a look at this? It's a small change to the http
server.
http://cr.openjdk.java.net/~michaelm/7110484/webrev.1/
I haven't included a regression test because to test it reliably would
require
at least a minute&
Looks good to me.
- Michael.
On 23/11/11 17:57, Chris Hegarty wrote:
This CR is simply to cleanup the style of the java.net.HttpCookie
source code. This has bugged me for a while!
1) Remove extraneous newlines
2) Use consistent javadoc comment style
3) Fix typos in public specification, sp
Hi,
This webrev fixes a bunch of test script issues in networking and core-libs.
In most if not all cases, the change relates to recognising the OS that
the test
is running on.
It also fixes an IPv6 issue, which requires Macos versions of a couple
of java.net
classes. These are the new files
On 14/12/11 19:54, Alan Bateman wrote:
On 14/12/2011 19:39, Michael McMahon wrote:
Hi,
This webrev fixes a bunch of test script issues in networking and
core-libs.
In most if not all cases, the change relates to recognising the OS
that the test
is running on.
It also fixes an IPv6 issue
Brandon,
The fix looks good to me. Thanks for contributing it.
- Michael.
On 15/12/11 23:14, Brandon Passanisi wrote:
Hello net-dev. I was wondering if somebody could review the
proposed fix for the following bug:
Bug URL: http:/
Updated webrev after Alan's comments.
http://cr.openjdk.java.net/~michaelm/7120875/webrev.2/
Thanks,
Michael.
On 14/12/11 19:39, Michael McMahon wrote:
Hi,
This webrev fixes a bunch of test script issues in networking and
core-libs.
In most if not all cases, the change relat
On 15/12/11 15:00, Chris Hegarty wrote:
CR 7095980: Ensure HttpURLConnection (and supporting APIs) don't
expose HttpOnly cookies
The changes use the internal/private java.net.HttpCookie parsing
implementation to filter out HttpOnly cookies from the Set-Cookie and
Set-Cookie2 headers returned in
On 19/12/11 14:11, Alan Bateman wrote:
On 16/12/2011 10:36, Michael McMahon wrote:
Updated webrev after Alan's comments.
http://cr.openjdk.java.net/~michaelm/7120875/webrev.2/
This is better but would be nice if we could avoid special casing
MacOSX in java.net.MulticastSocket. Given th
On 22/12/11 13:34, Alan Bateman wrote:
On 22/12/2011 11:46, Michael McMahon wrote:
I've updated this to localize the changes to NetworkInterface (and
the new class DefaultInterface).
So, there's no change to the socket impl java code
The new native code implementation is in net
On 22/12/11 13:46, Michael McMahon wrote:
On 22/12/11 13:34, Alan Bateman wrote:
On 22/12/2011 11:46, Michael McMahon wrote:
I've updated this to localize the changes to NetworkInterface (and
the new class DefaultInterface).
So, there's no change to the socket impl java code
The
Could I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7125722/webrev.1/
JNI field ids were being used before being initialized.
Thanks,
Michael.
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/
The asynchronous close mechanism was not being compiled for Mac OS.
Also, the pthread mutexes used by this code, need to be explicitly
initialized
on Mac, which was not being done previousl
On 09/01/12 16:15, Alan Bateman wrote:
On 09/01/2012 16:03, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7127660/webrev.1/
The asynchronous close mechanism was not being compiled for Mac OS.
Also, the pthread mutexes used by
On 10/01/12 15:01, Chris Hegarty wrote:
Since the integration of the HTTPOnly changes, CR 7095980, the map
returned by HttpURLConnection.getHeaderFields is not unmodifiable.
This is contradaction to the API specification.
URLConnection.getHeaderFields() : "Returns an unmodifiable Map of the
h
Yes, looks fine to me too. I would just update the comment above this
code to add Mac OS to the Solaris case.
Thanks
Michael
On 13/01/12 21:02, Kurchi Hazra wrote:
How does this look: http://cr.openjdk.java.net/~khazra/7127771/webrev.01/
- Kurchi
On 1/13/2012 12:14 PM, Alan Bateman wrote:
On 16/01/12 11:39, Chris Hegarty wrote:
The system-wide CookieHandler is read and stored in the
sun.net.www.http(s) HttpClient/HttpsClient instance. Since this
HttpClient/HttpsClient instance is cached and reused (where possible)
as part of the persistent/keep-alive connection implementation, i
Looks fine.
- Michael.
On 17/01/12 19:01, Kurchi Hazra wrote:
I updated the comment:
http://cr.openjdk.java.net/~khazra/7127771/webrev.02/
- Kurchi
On 1/16/2012 2:43 AM, Michael McMahon wrote:
Yes, looks fine to me too. I would just update the comment above this
code to add Mac OS to the
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge case
tested by JCK,
namely, when a zero length UDP message is sent on a DatagramSocket. The
problem is only
detected on t
On 23/01/12 17:09, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge
case tested by JCK,
namely, when a zero length UDP message is sent
On 23/01/12 21:30, Alan Bateman wrote:
On 23/01/2012 17:09, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
The problem is that poll(2) doesn't seem to work in a specific edge
case tested by JCK,
namely, w
in other native code (in AWT)
and I don't want to affect those usages. Granted that raises a question
as to whether they
are affected by this bug. But, I don't believe they are since, as far as
I can see UDP sockets
aren't used there.
- Michael
-Chris.
On 01/23/12 10:32 PM, M
On 24/01/12 10:46, Alan Bateman wrote:
On 23/01/2012 22:32, Michael McMahon wrote:
No, I don't think so. fd_sets are bit masks and you have to specify
the highest numbered bit in the
mask (+1).
Sorry, I wasn't thinking, it's nfds+1.
In that case, I think the change is okay al
On 24/01/12 11:27, Damjan Jovanovic wrote:
On Mon, Jan 23, 2012 at 7:09 PM, Michael McMahon
mailto:michael.x.mcma...@oracle.com>>
wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/
<http://cr.openjdk
Can I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7139770/webrev.1/
There are two issues. In DatagramSocket the change uses the peekData()
api when available, instead of peek(), which in fact doesn't work at all
with our own PlainDatagramSocketImpl (it tries t
Can I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/7132699/webrev.1/
On Mac, we read the system proxy settings and
by default the system sets a proxy bypass list. Unfortunately, this
default list doesn't contain some entries (like localhost) which we depend
on t
to an
implementation class.
http://cr.openjdk.java.net/~michaelm/7122794/webrev.3/
Thanks
Michael
On 29/01/12 20:23, Michael McMahon wrote:
Can I get the following webrev reviewed please.
http://cr.openjdk.java.net/~michaelm/7122794/webrev.1/
Thanks,
Michael
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7142123/webrev.1/
The fix for 7141335 (on Mac) caused a regression on all platforms
breaking the fix fo 6737819. This was testing a very unusual usage of
proxies,
but one we probably have to support anyway, whi
On 08/02/12 21:07, chris hegarty wrote:
This seems to be an oversight in HttpURLConnection where the
system-wide ResponseCache handler is used to store responses even if
getUsesCaches returns false.
I guess this was never really noticed before since the cached response
will not be used if get
Could I get the following webrev reviewed please for 7u4?
http://cr.openjdk.java.net/~michaelm/7146564/webrev.1/
Something I overlooked in the recent change to the DefaultProxySelector
is that some of our tests end up trying to connect to 0.0.0.0
and that needs to be added to the default proxy l
nds up being proxied by default
on Mac.
- Michael.
-Chris.
On 02/17/12 12:26 PM, Michael McMahon wrote:
Could I get the following webrev reviewed please for 7u4?
http://cr.openjdk.java.net/~michaelm/7146564/webrev.1/
Something I overlooked in the recent change to the DefaultProxySelector
is th
Deven,
The change looks benign enough, but my only concern is that not all
operating systems appear to support pinging 0.0.0.0. What is the official
position on 0.0.0.0 as a destination address?
- Michael.
On 23/04/12 06:57, Deven You wrote:
On 04/09/2012 03:57 PM, Deven You wrote:
Hi net-dev
Could I get the following small change reviewed for 7u6?
http://cr.openjdk.java.net/~michaelm/7146564/webrev.1/
The change has been in 8 already for some time.
Thanks
Michael.
Looks fine.
- Michael
On 25/06/12 11:49, Chris Hegarty wrote:
This is a trivial (2 line) change to increase the size of a native
buffer being passed to InitializeSecurityContext. We have seen reports
of InitializeSecurityContext failing with SEC_E_INSUFFICIENT_MEMORY,
given the needed buffer
On 11/07/12 08:00, Alan Bateman wrote:
On 05/07/2012 07:10, Deven You wrote:
Hi All,
I noticed that InetAddress.getLocalHost() uses cache to improve the
performance. However the default implementation is caching local host
within 5 seconds.
From the spec, networkaddress.cache.ttl should be
Hi,
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7183292/webrev.1/
Since 7u4, we are parsing all incoming cookies via the HttpCookie class.
This class has had a restriction on cookie names that is causing this
problem
and which is not required by any o
well - assuming that it is
being used in places
(albeit in contravention of the older RFC). What do you think?
- Michael
On 17/07/2012 14:18, Chris Hegarty wrote:
On 17/07/2012 10:17, Michael McMahon wrote:
Hi,
Could I get the following change reviewed please?
http://cr.openjdk.java.net
read the sections dealing with cookie-name in 6265, and these
changes look good to me.
- Kurchi
On 7/17/12 7:32 AM, Michael McMahon wrote:
Thanks for reviewing this Chris. On the question of whether $ should
be allowed
in cookie names, it appears like that restriction has been removed
from RFC
This is the same change for 7u6. The change is identical.
http://cr.openjdk.java.net/~michaelm/7183292/webrev.7u6.2/
Thanks,
Michael
On 18/07/12 18:38, Michael McMahon wrote:
Thanks Kurchi.
I have made one small change to another test, which was specifically
testing the $name assertion
this particular bug
fix, we will keep it in 7u.
http://cr.openjdk.java.net/~michaelm/7183292/webrev.7u6.3/
Thanks
Michael
On 18/07/12 18:47, Michael McMahon wrote:
This is the same change for 7u6. The change is identical.
http://cr.openjdk.java.net/~michaelm/7183292/webrev.7u6.2/
Thanks,
Michael
we declare these fallback properties so I have
no idea where I can do the same thing for
networkaddress.cache.localhost.ttl.
Please take a look.
Thanks a lot!
On 07/11/2012 06:55 PM, Michael McMahon wrote:
On 11/07/12 08:00, Alan Bateman wrote:
On 05/07/2012 07:10, Deven You wrote:
Hi All,
Could I get this change reviewed please? It is a simple
documentation change to explicitly permit implementations to
only support loopback networking (ie. external networking not required).
http://cr.openjdk.java.net/~michaelm/7120665/webrev.1/
Thanks,
Michael.
On 30/07/12 22:00, Alan Bateman wrote:
On 30/07/2012 21:57, Michael McMahon wrote:
Could I get this change reviewed please? It is a simple
documentation change to explicitly permit implementations to
only support loopback networking (ie. external networking not required).
http
/webrev.03/
<http://cr.openjdk.java.net/%7Eyoudwei/ojdk-527/webrev.02/>
Thanks a lot!
On 07/25/2012 11:19 PM, Michael McMahon wrote:
On 24/07/12 07:17, Deven You wrote:
Hi Alan and Michael,
I add a java doc[1] for the new networkaddress.cache.localhost.ttl
property. Please take a look wh
Hi,
A new revision of the Http client API planned for jdk 8 can be viewed
at the following link
http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
We would like to review the api on this mailing list.
So, all comments are welcome.
Thanks
Michael McMahon.
.
Thanks again,
Michael.
On 08/08/12 00:09, Michael McMahon wrote:
Hi,
A new revision of the Http client API planned for jdk 8 can be viewed
at the following link
http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
We would like to review the api on this mailing list.
So, all comments are welcome
Hi,
We have just published a draft of a proposed new Http client API [1] for
JDK 8.
This message has been bcc'd to jdk8-dev so that as many people as possible
know about it, but the discussion will be on the net-dev list
(net-dev@openjdk.java.net).
So, folks will have to join that list [2],
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1] for
JDK 8.
This message has been cc'd to jdk8-dev so that as many people as possible
know about it, but the discussion will be on the net-dev list
(net-dev@openjdk.java.net).
So, folks
was wondering maybe it is
OK to detach the HostnameVerifier interface and remove the verify() method.
Maybe, you have other concerns that the HttpsConfigurator.verify()
method is really needed.
Thanks,
Xuelei
On 8/8/2012 7:09 AM, Michael McMahon wrote:
Hi,
A new revision of the Http client A
On 08/08/12 21:35, Chris Hegarty wrote:
Great suggestion Anthony,
This is something that comes up from time to time. With the clear
distinction between java.net.HttpURLConnection and
javax.net.ssl.HttpsURLConnection API's then it was a little difficult
to do in the existing API, but there is
hat the Iterable can only be used to
return one Iterator instance.
HttpConnectionCache.CachedConnection::
- I would expect this to be abstract and that client providers would extend.
- getCache() to return the client provider.
On Aug 7 2012, at 16:09 , Michael McMahon wrote:
Hi,
A new rev
On 09/08/12 10:50, Chris Hegarty wrote:
On 09/08/12 00:00, Jed Wesley-Smith wrote:
Michael McMahon writes:
A new revision of the Http client API planned for jdk 8 can be viewed
at the following link
http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
We would like to review the api on
On 09/08/12 01:49, David M. Lloyd wrote:
On 08/07/2012 06:09 PM, Michael McMahon wrote:
Hi,
A new revision of the Http client API planned for jdk 8 can be viewed
at the following link
http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/
We would like to review the api on this mailing list
On 15/08/12 16:59, Mike Duigou wrote:
On Aug 15 2012, at 09:06 , Michael McMahon wrote:
HttpClientProvider::
- HttpClientProvider JavaDoc uses inconsistent capitalization of HTTP.
- createAsynchronousHttpClient() Since there's only one create method why bother to
mention that
On 08/08/12 20:09, Ian Robertston wrote:
Instead of HttpRequest having
void setBody(Iterable buffers, boolean isRestartable)
what about having two methods:
void setBody(Iterable buffers) // presumed restartable
void setBody(Iterator buffers) // clearly not restartable
Not only doe
t a blocking application will just block until
the 100 continue is received, before being allowed to send the body.
An asynchronous application will just not be "called back" to get the body
until the 100 is received.
Thanks
Michael
-Chris.
On 08/08/12 00:09, Michael McMahon wrote:
Hi,
On 17/08/12 11:59, Frank Carver wrote:
On 17 August 2012 11:30, Michael McMahon wrote:
2) What is the impact on the sendHeader, setBody for HEAD requests?
Ah yes, HEAD needs special treatment - though not with respect to the methods
above as HEAD is identical to GET except with respect to
mantics will survive.
Right. This is important. One area where there will be changes is with
pipe-lining.
We need to ensure that our pipe-lining API is not restricted to only
Http 1.1 pipe-lining
Are you aware of other areas that could have an impact on the API?
Thanks
Michael.
Sam
On Tue, Aug
/08/2012 14:57, Michael McMahon wrote:
Sam,
Thanks for the comments. Some discussion below.
On 17/08/12 00:13, Sam Pullara wrote:
I suggest that you make it a more fluent API rather than having
multiple callback methods in your callback interface. As it stands it
isn't compatible with lambdas.
On 22/08/12 22:09, Sam Pullara wrote:
On Aug 22, 2012, at 1:17 PM, Chris Hegarty wrote:
On 22/08/12 21:05, Michael McMahon wrote:
On 22/08/12 15:29, Chris Hegarty wrote:
Michael what you have looks good.
But, I think what Sam is suggesting ( or maybe not, but I like it ;-)
), is something
ctionality is
all defined using the same artifacts. But, my imagination is currently is
failing me on how to improve on such matters. Perhaps something better may come
out of fluent-based API?
Paul.
On Aug 14, 2012, at 2:01 PM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
On 23/08/12 18:50, Shirish Kuncolienkar wrote:
Could I get the change reviewed please
This behavior is seen on Windows.
Logic in URLClassPath.getLoader() does not take care of an URL which
looks like "jar:file:/C:/test/xyz.jar!/". The logic ends up choosing a
FileLoader instead of a JarLoader.
Hello,
I have just posted the javadoc for v 0.4 of the Http client API [1]
This draft takes into account almost all of the feedback from
the last round of reviews. There are a small number of issues
still outstanding however.
For those who are not aware, the development work done so
far has been
John,
Maybe SimpleHttpsServer should be named TestHttpsServer to be similar
to the Http equivalent. Otherwise, it looks fine to me.
And I think we'll look into migrating these tests to use the
com.sun.net.httpserver
API instead of that old implementation in the test tree.
Thanks
Michael
On 0
One useful feature in Netbeans is that you can select a block
of code and just (re)format that. So, there's no need to worry
about affecting the rest of the file you are editing.
- Michael
On 14/09/12 01:59, Weijun Wang wrote:
On 09/14/2012 08:21 AM, Brad Wetmore wrote:
Netbean's automatic f
There is a JSR for websockets, and they are doing a reference implementation
based on JDK 7 I believe.
As regards TCP sockets via Http proxies, JDK doesn't support that.
The closest thing is probably SOCKS. Can you use that?
- Michael
On 25/10/12 14:32, Vasiliy Baranov wrote:
Greetings,
And a
build something with it, which I'd be
happy to give a try at.
Thanks
Richard
On Aug 14, 2012, at 5:01 AM, Michael McMahon
wrote:
Hi,
(apologies for sending this again)
We have just published a draft of a proposed new Http client API [1] for JDK 8.
This message has been cc'd to jdk8-dev
/2012 05:32 PM, Michael McMahon wrote:
Deven
Is there a bugid for this? We need to submit a CCC request also to
make the spec change.
Thanks
Michael
On 31/07/12 08:14, Deven You wrote:
Hi Michael,
Thanks for your review, I have updated the patch[1] according to
your comments.
[1] http
Could I get the following change reviewed please?
There was a crash caused by accessing freed memory when
authentication was repeated in the same HttpURLConnection instance/
http://cr.openjdk.java.net/~michaelm/7200720/webrev.1/
Thanks
Michael
On 23/11/12 16:16, Alan Bateman wrote:
On 23/11/2012 15:59, Michael McMahon wrote:
Could I get the following change reviewed please?
There was a crash caused by accessing freed memory when
authentication was repeated in the same HttpURLConnection instance/
http://cr.openjdk.java.net/~michaelm
On 23/11/12 16:16, Alan Bateman wrote:
On 23/11/2012 15:59, Michael McMahon wrote:
Could I get the following change reviewed please?
There was a crash caused by accessing freed memory when
authentication was repeated in the same HttpURLConnection instance/
http://cr.openjdk.java.net/~michaelm
Hi,
I have just posted another draft of the http client API for review.
This will be the final round of review before we submit it to the CCC.
It can be seen at:
http://cr.openjdk.java.net/~michaelm/httpclient/CCCv1.1/javadoc/
Probably the biggest change is that we removed the multiple overloa
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/
We need to filter out extraneous authentication headers when doing
ntlm authentication with MS web servers and proxies.
Thanks
Michael
Thanks!
On 10/12/12 14:50, Chris Hegarty wrote:
On 10/12/2012 14:34, Weijun Wang wrote:
Looks fine.
+1
-Chris
-Max
On 12/10/2012 10:30 PM, Michael McMahon wrote:
Could I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/8003948/webrev.1/
We need to filter
Could I get the following webrevs reviewed please?
They are identical changes (except for one small change suggested by Dmitry)
to what was done in 8 for the same issues
http://cr.openjdk.java.net/~michaelm/7200720.7u-dev/webrev.1/
http://cr.openjdk.java.net/~michaelm/8003948.7u-dev/webrev.1/
T
On 10/12/12 20:48, Dmitry Samersoff wrote:
Michael,
On 2012-12-10 23:35, Michael McMahon wrote:
Could I get the following webrevs reviewed please?
They are identical changes (except for one small change suggested by
Dmitry)
to what was done in 8 for the same issues
http://cr.openjdk.java.net
On 10/12/12 16:01, Chris Hegarty wrote:
Inet6Address.getHostAddress() is specified to return the IP address
string in textual presentation, followed by a '%' character and the
scope identifier. This scope identifier can be either a numeric value
or a string, depending on how the instance was
JEP 110: "New Http Client" is a feature intended for Java SE 8 which
aims to provide a new client API for http, and which leverages some of the
new features in recent releases of Java SE, such as asynchronous sockets
in NIO
and Lambda expressions.
A significant amount of work has been done so
Hi Bruno,
This sounds similar to what URI.resolve() provides:
For example:
new URI("http://www.foo.com/a/b/c";).resolve("")
returns http://www.foo.com/a/b/
URL has a constructor which does something similar
(the URL(URL, String) one)
- Michael
On 15/01/13 22:18, Bruno Borges wrote:
Hey fo
David,
Thanks for the comments. I agree we need to be careful not to break
existing security
assumptions. One general point I'd make though is if CORS is to be the
standard for cross-origin
web clients built using Javascript, then why would we not allow Java
based clients interact with
server
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 permi
On 26/04/13 16:47, Alan Bateman wrote:
On 26/04/2013 15:36, Michael McMahon wrote:
:
The API change can be seen at the URL below:
http://cr.openjdk.java.net/~michaelm/8010464/api/
One comment on the "Security permissions" section of HttpURLConnection
is that it "caller must
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
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 &qu
t;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:He
lon) 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, Dmitr
alue) 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 r
On 07/05/13 14:43, Chris Hegarty wrote:
On 05/06/2013 10:28 PM, Kurchi Hazra wrote:
This looks okay to me.
Source changes look fine to me too. Probably best to add a test for '$'
In fact, Michael actually removed such a test [1] during another
change. We should get positive agreement from Mi
On 08/05/13 09:50, Chris Hegarty wrote:
On 08/05/2013 10:35, Michael McMahon wrote:
On 07/05/13 14:43, Chris Hegarty wrote:
On 05/06/2013 10:28 PM, Kurchi Hazra wrote:
This looks okay to me.
Source changes look fine to me too. Probably best to add a test for '$'
In fact, Michae
Hi,
This is the webrev for the HttpURLPermission addition.
As well as the new permission class, the change
includes the use of the permission in java.net.HttpURLConnection.
The code basically checks for a HttpURLPermission in plainConnect(),
getInputStream() and getOutputStream() for the request
don't believe it needs to be synchronized since the method is not
relying on
consistency between object fields, and the returned object can be
modified before, during or after the method is called anyway.
Michael
On 12/05/13 08:13, Alan Bateman wrote:
On 10/05/2013 12:34, Michael McMahon
901 - 1000 of 1041 matches
Mail list logo
