://bernd.eckenfels.net
Von: net-dev im Auftrag von Michael
McMahon
Gesendet: Monday, March 7, 2022 12:04:02 PM
An:net-dev@openjdk.java.net
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
On Fri, 4 Mar 2022 14:59:48 GMT, Weijun Wang wrote:
Hi
I'm wrong. It is implemented in the security libs. So, that means we can
support it also
Michael
On 07/03/2022 12:24, Michael McMahon wrote:
Bernd,
In that case we should defer to the security libraries to implement
SHA-512-256, which does not seem to be supported currently. We al
On Sat, 5 Mar 2022 15:07:15 GMT, Jaikiran Pai wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the
>> MD5 message digest algorithm by default in the HTTP Digest authentication
>> mechanism? The algorithm can be opted into by setting a new system propert
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMahon
On Mon, 7 Mar 2022 20:35:13 GMT, Sean Mullan wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/sha
On Wed, 9 Mar 2022 15:53:02 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>> line 85:
>>
>>> 83: public String run() {
>>> 84: return Security.getProperty(secPropName)
>>> 85:
On Wed, 9 Mar 2022 14:23:24 GMT, Weijun Wang wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/sha
On Wed, 9 Mar 2022 15:18:43 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/sha
On Wed, 9 Mar 2022 15:41:08 GMT, Weijun Wang wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/sha
On Thu, 10 Mar 2022 14:21:41 GMT, Weijun Wang wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/share/
On Thu, 10 Mar 2022 14:26:28 GMT, Weijun Wang wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/
On Thu, 10 Mar 2022 15:02:17 GMT, Weijun Wang wrote:
>> Michael McMahon has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update
>> - update after first review round
>
> src/java.base/sha
On Mon, 7 Mar 2022 14:41:47 GMT, Weijun Wang wrote:
>> 2nd test of https://datatracker.ietf.org/doc/html/rfc7616#section-3.9 is on
>> this algorithm, but it requires UTF-8 charset support and a way to provide a
>> predefined cnonce. If it's not worth modifying our implementation to create
>> a
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMahon
On Fri, 11 Mar 2022 17:37:44 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the
>> MD5 message digest algorithm by default in the HTTP Digest authentication
>> mechanism? The algorithm can be opte
On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs wrote:
>> Please find enclosed a patch that solves an intermittent issue detected by
>> the CancelRequestTest.java
>>
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled
>> after the Http2Connection has been created, and
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMahon
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMa
On Thu, 10 Mar 2022 17:05:32 GMT, Daniel Fuchs wrote:
>> Please find enclosed a patch that solves an intermittent issue detected by
>> the CancelRequestTest.java
>>
>> If during an HTTP upgrade from HTTP/1.1 to HTTP/2, the request is cancelled
>> after the Http2Connection has been created, and
On Mon, 14 Mar 2022 13:21:21 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java
>> line 155:
>>
>>> 153: boolean offerConnection(Http2Connection c) {
>>> 154: if (debug.on()) debug.log("offering to the connection pool:
>>> %s", c)
On Fri, 11 Mar 2022 18:12:27 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update after second review round
>
> src/java.base/share/cla
On Mon, 14 Mar 2022 16:45:24 GMT, Aleksei Efimov wrote:
>> The following fix seals the `java.net.InetAddress` class and permits only
>> two implementations - `java.net.Inet4Address` and `java.net.Inet6Address`.
>>
>> No issues have been detected by regression and JCK tests.
>>
>> Links: [JBS]
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMahon
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMa
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMahon
On Fri, 25 Mar 2022 15:07:40 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Could I get the following change reviewed please, which is to disable the
>> MD5 message digest algorithm by default in the HTTP Digest authentication
>> mechanism? The algorithm can be opte
On Fri, 25 Mar 2022 17:21:11 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> forgot update to DigestAuth test
>
> src/java.base/share/cla
On Mon, 28 Mar 2022 09:29:58 GMT, Daniel Fuchs wrote:
>> No, the digest field refers to the actual message digest algorithm (as known
>> to the security libraries). The algorithm field holds the algorithm name as
>> it is defined in RFC7616.
>
> I am confused here - because you converted `algo
s" to include the value MD5. The change also
> updates the Digest authentication implementation to use some of the more
> secure features defined in RFC7616, such as username hashing and additional
> digest algorithms like SHA256 and SHA512-256.
>
> - Michael
Michael McMa
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following change reviewed please, which is to disable the MD5
> message digest algorithm by default in the HTTP Digest authentication
> mechanism? The algorithm can be opted into by setting a new
On Tue, 29 Mar 2022 19:43:50 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java line
>> 302:
>>
>>> 300:
>>> 301: // GET with no body should not set the Content-Length header
>>> 302: if (requestPublisher != null ||
>>> !"GET".e
On Thu, 10 Mar 2022 11:17:26 GMT, Daniel Fuchs wrote:
>> These changes make sure that pending requests are terminated if the selector
>> manager thread exits due to exceptions.
>> This includes:
>>1. completing CompletableFutures that were returned to the caller code
>>2. cancelling requ
On Thu, 14 Apr 2022 18:45:10 GMT, Daniel Fuchs wrote:
>> java/net/httpclient/http2/TLSConnection.java has been observed failing (even
>> though rarely) in test jobs.
>>
>> The issue is that the handler used on the the server sides maintains a
>> volatile `sslSession` field which it sets when r
Hi,
Could I get the following PR review please? It adds a new JDK specific extended
socket option
called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4 and
IPv6
UDP sockets (NIO DatagramChannels). For IPv4 in particular, it sets the DF
(Dont Fragment) bit
in the IP header.
On Fri, 15 Apr 2022 09:19:48 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Could I get the following PR review please? It adds a new JDK specific
>> extended socket option
>> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
>> and IPv6
>> UDP sockets (NIO DatagramChannels).
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additional
On Fri, 15 Apr 2022 10:04:48 GMT, Daniel Jeliński wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> builds in github action now
>
> src/jdk.net/windows/native/libextnet/WindowsSoc
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request with a new target base due to a
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additional
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one addition
On Tue, 19 Apr 2022 14:50:57 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix whitespace
>
> src/jdk.net/windows/native/libextnet/WindowsSocke
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additional
On Tue, 19 Apr 2022 16:07:29 GMT, Daniel Fuchs wrote:
>> I'm not sure there is value in testing all of these permutations.
>> Distinguishing DatagramChannel and DatagramSocket probably made sense, but
>> it's all the same implementation under the hood.
>
> 1. `DatagramChannel.open()` => opens a
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additiona
Hi,
https://bugs.openjdk.java.net/browse/JDK-8285240
contains the release note for the TLS Channel binding enhancement in JDK
19 added in:
https://bugs.openjdk.java.net/browse/JDK-8279842
(PR: https://github.com/openjdk/jdk/pull/7065)
The release note uses the explanatory text from the CSR
On Sat, 16 Apr 2022 11:06:21 GMT, Daniel Fuchs wrote:
>> These changes make sure that pending requests are terminated if the selector
>> manager thread exits due to exceptions.
>> This includes:
>>1. completing CompletableFutures that were returned to the caller code
>>2. cancelling requ
> (Dont Fragment) bit
> in the IP header. There is no equivalent in the IPv6 packet header as
> fragmentation is implemented
> exclusively by the sending and receiving nodes.
>
> Thanks,
> Michael
Michael McMahon has updated the pull request incrementally with one additiona
On Thu, 14 Apr 2022 16:04:22 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following PR review please? It adds a new JDK specific
> extended socket option
> called IP_DONTFRAGMENT, which disables IP packet fragmentation in both IPv4
> and IPv6
> UDP sockets (NIO D
Hi,
Could I get the following small test update reviewed please?
It includes a test scenario that should have been included with JDK-8284890
Thanks,
Michael
-
Commit messages:
- test update
Changes: https://git.openjdk.java.net/jdk/pull/8405/files
Webrev: https://webrevs.openjdk.
On Tue, 26 Apr 2022 16:41:08 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following small test update reviewed please?
> It includes a test scenario that should have been included with JDK-8284890
>
> Thanks,
> Michael
I'm closing this PR as the rela
On Tue, 26 Apr 2022 16:41:08 GMT, Michael McMahon wrote:
> Hi,
>
> Could I get the following small test update reviewed please?
> It includes a test scenario that should have been included with JDK-8284890
>
> Thanks,
> Michael
This pull request has been closed wit
Hi,
Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday
and is causing failures on older versions of macOS that do not support the
option. The fix here is to check at initialization time whether it is supported
before adding it to the list of supported options. The err
On Wed, 27 Apr 2022 09:43:52 GMT, Michael McMahon wrote:
> Hi,
>
> Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday
> and is causing failures on older versions of macOS that do not support the
> option. The fix here is to check at initialization tim
On Wed, 27 Apr 2022 09:43:52 GMT, Michael McMahon wrote:
> Hi,
>
> Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday
> and is causing failures on older versions of macOS that do not support the
> option. The fix here is to check at initialization tim
On Wed, 27 Apr 2022 11:02:08 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Can I get the following fix reviewed please? JDK-8284890 was pushed
>> yesterday and is causing failures on older versions of macOS that do not
>> support the option. The fix here is to check at initialization time whether
>>
list of supported options. The error causes
> the new test and two existing ones to fail. I will remove the two tests from
> the problem list separately.
>
> Thanks,
> Michael.
Michael McMahon has updated the pull request incrementally with one additional
commit since t
On Wed, 27 Apr 2022 14:10:55 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated test
>
> src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line
On Wed, 27 Apr 2022 14:12:40 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updated test
>
> test/jdk/jdk/net/ExtendedSocketOption/DontFragmentTest.java line 44
list of supported options. The error causes
> the new test and two existing ones to fail. I will remove the two tests from
> the problem list separately.
>
> Thanks,
> Michael.
Michael McMahon has updated the pull request incrementally with one additional
commit since
On Wed, 27 Apr 2022 09:43:52 GMT, Michael McMahon wrote:
> Hi,
>
> Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday
> and is causing failures on older versions of macOS that do not support the
> option. The fix here is to check at initialization tim
On Wed, 27 Apr 2022 15:27:45 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psu
On Sat, 30 Apr 2022 09:55:16 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psu
On Thu, 5 May 2022 12:55:57 GMT, Michael Felt wrote:
>> with IP "0.0.0.0"
>>
>> - it either does nothing and ping fails, or, in some virtual environments
>> is treated as the default route address.
>> - IPv6 support for ::1 is available since 1977; however, ::0 is not accepted
>> as a vaild psue
On Sat, 7 May 2022 11:46:32 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a simple test fix that re-architecture ShortResponseBody
>> for better resource usage.
>> The test is split to test GET and POST separately and avoids testing GET
>> twice.
>
> Daniel Fuchs has updated the pull
On Mon, 9 May 2022 12:37:59 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find here a simple test fix that re-architecture ShortResponseBody
>> for better resource usage.
>> The test is split to test GET and POST separately and avoids testing GET
>> twice.
>
> Daniel Fuchs has updated the pull
On Tue, 10 May 2022 13:51:37 GMT, Jaikiran Pai wrote:
>> This change proposes to implement the enhancement noted in
>> https://bugs.openjdk.java.net/browse/JDK-8209137.
>>
>> The change introduces a new API to allow applications to build a
>> `java.net.http.HTTPClient` configured with a specif
On Wed, 11 May 2022 08:54:48 GMT, Jaikiran Pai wrote:
>> src/java.net.http/share/classes/java/net/http/HttpClient.java line 378:
>>
>>> 376: *
>>> 377: * @implSpec The default implementation of this method throws
>>> 378: * {@code UnsupportedOperationException}. {@code
On Wed, 11 May 2022 15:42:25 GMT, Daniel Fuchs wrote:
> In relation to
> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
> here a patch that addresses possibly lossy conversions in java.net.http
src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffm
On Wed, 11 May 2022 17:10:45 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/hpack/QuickHuffman.java
>> line 739:
>>
>>> 737: buffer |= (codeValueOf(c) >>> bufferLen); //
>>> append
>>> 738: bufferLen += (int) le
On Thu, 12 May 2022 10:51:04 GMT, Daniel Fuchs wrote:
>> In relation to
>> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find
>> here a patch that addresses possibly lossy conversions in java.net.http
>
> Daniel Fuchs has updated the pull request incrementally with one
On Sat, 7 May 2022 11:46:37 GMT, Daniel Fuchs wrote:
>> Hi, please find here a patch that solves a rare intermittent test failure
>> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>>
>> A race condition coupled with some too eager synchronization was causing a
>> deadlock bet
On Sat, 7 May 2022 11:46:37 GMT, Daniel Fuchs wrote:
>> Hi, please find here a patch that solves a rare intermittent test failure
>> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>>
>> A race condition coupled with some too eager synchronization was causing a
>> deadlock bet
On Sun, 15 May 2022 06:43:27 GMT, Jaikiran Pai wrote:
>> This change proposes to implement the enhancement noted in
>> https://bugs.openjdk.java.net/browse/JDK-8209137.
>>
>> The change introduces a new API to allow applications to build a
>> `java.net.http.HTTPClient` configured with a specif
Andreas Schaefer wrote:
Michael McMahon wrote:
Andreas Schaefer wrote:
Michael McMahon wrote:
Christopher Hegarty - Sun Microsystems Ireland wrote:
Andreas Schaefer wrote:
> Well, the reason I did make it abstract is the fact that I did
want to
av
Richard Kennard wrote:
Alan,
Thanks for your continued support.
I find the 'static factory method' approach interesting, but I'm a
little confused. You cite 'being able to return a subclass' as an
advantage. However, you also recommend a private constructor and
classes with private construct
Richard Kennard wrote:
What we have left appear to be some fairly small details. If I may
summarise, you are saying...
Yes, I think that is true.
1) java.net.URL is discouraged, therefore we shouldn't support it in
our API nor follow its naming convention (even though we'll sit
alongside it
Richard Kennard wrote:
Michael,
>> 1) java.net.URL is discouraged... I would agree with Alan on this.
Fair enough: I shall remove those methods.
Can you confirm you want the naming convention changed to Url? It's
just that everything else in the package uses uppercase URL (for
legacy reasons
Richard Kennard wrote:
Michael,
I just thought I'd tackle this point in detail...
Here we agree! And with the current version of the code, this works...
URLEncodedQueryString queryString =
URLEncodedQueryString.create();
queryString.setParameter( "a", "x&y" );
queryString
The CCC request has received initial approval,
which simply means that the API change is accepted in principle.
But, we need to finalize the specification and submit it to the CCC
for final approval.
Due to the (large) amount of discussion that has already
taken place, I don't anticipate that thi
Richard Kennard wrote:
Michael,
Given that I sort of disagree with both these comments, should I just
take it that this is what the CCC wants and make the changes anyway?
My disagreements would be:
1. Overkill or not, surely defining an enum is more explicit, more
type-safe and a generally
Richard Kennard wrote:
Michael,
Though I think we should stick with the uppercase convention.
Agreed.
What are you suggesting here?
Nothing different to what I have been saying before. HTML requires us
to have the 'multi-valued return' feature, but I think if the API
looks like...
clas
Some other minor comments on the last draft.
- Michael.
Class intro docs.
1. In the section entitled "Multivalued parameters" the list refers to
getParameterValue()
This should be getParameter()
2. The first reference to "(ampersand and semicolon)" should inlcude the
actual symbols
th
4. Will the result of getParameterMap preserves the name order? If
not, does this mean that UrlEncodedQueryString.create
(q.getParameterMap()) may not equals to q?
Thanks
Max
On Jul 16, 2007, at 8:06 PM, Michael McMahon wrote:
I have updated the CCC request for this, and would like
to finalize
-> method.
2) getParameterValues. returns a List not an array. The method
description also needs to be updated.
3) getParameterMap. Same as 2)
4) How does setParameters(java.lang.String) handle Separators?
5) ditto for appendParameters.
6) apply(URI, UrlEncodedQueryString.Separator). '
4) How does setParameters(java.lang.String) handle Separators?
5) ditto for appendParameters.
6) apply(URI, UrlEncodedQueryString.Separator). 'Separator' in the
parameter list should start with lowercase 's'.
-Chris.
Michael McMahon wrote:
I have updated the CCC request for this, an
--- Begin Message ---
Max (Weijun) Wang wrote:
1. How about setParameters(String name, List values) so that I
can set a multivalued parameter in one call?
I think the most likely use case, is when you dynamically add the
parameters one at a time,
but that case is certainly possible. But I'd
tion also needs to be updated.
3) getParameterMap. Same as 2)
4) How does setParameters(java.lang.String) handle Separators?
5) ditto for appendParameters.
6) apply(URI, UrlEncodedQueryString.Separator). 'Separator' in the
parameter list should start with lowercase 's'.
-Chr
Richard Kennard wrote:
Chris,
Thanks for your feedback. And actually, picky is good! I much prefer
picky feedback to no feedback at all.
I have updated the JavaDoc with your suggestions:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=20922&forumID=1463
The CCC request for this feature was finalised on 13 August.
We've had one comment back so far relating to the sample code in the docs.
It seems the samples still refer to the old constructors rather than the
factory creation
methods. I've updated the docs to fix this.
- Michael.
I agree with most of the suggestions below. The main things
we want are:
1) alignment, ie. the JSR311 class extends the java.net class
although I would imagine that if JSR311 is finalised before jdk7
then it will not initially extend it. So, it should at least be aligned
sufficiently so
Marc & Paul,
I wonder if you have an opinion on the points/questions raised below?
I'd like to get agreement on the general shape of the API before
anyone goes off and reworks the existing proposal.
Thanks
Michael.
Michael McMahon wrote:
I agree with most of the suggestions below.
Here is my suggestion. It probably makes sense to keep two separate
classes, even though UriBuilder can potentially
be used to create any possible URI. I think it is still useful to be
able to manipulate query parameters independent
of the URI that they are to be applied to, and I think the abi
Hi Cormac,
I don't think it's likely that Java SE will support RFC3542 in the near
future.
I can't say however, whether anybody is actually doing any work on
trying to support it.
It seems like a fairly specialised requirement, that the majority of
IPv6 applications would
not use.
Have you l
using...
Yes, this is right place.
Has there been any work on the bug I referred to in the subject? If
not, read on.
Michael McMahon is probably the best person to reply to you on this.
Last year he had a proposal and implementation that updated
DatagramPacket with methods to obtain the dat
Looks ok to me.
- Michael.
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi,
I need to get a code review for,
CR 6687282 : "URLConnection for HTTPS connection through Proxy w/
Digest Authentication gives 400 Bad Request".
Digest authentication uses the request-URI as part of its a
David M. Lloyd wrote:
On 06/18/2008 11:03 AM, Christopher Hegarty - Sun Microsystems Ireland
wrote:
I think that this thread should be moved to the net-dev alias.
I know that Michael is certainly a member of net-dev and is currently
the owner of the HTTP server.
OK, great. To restate the or
David M. Lloyd wrote:
On 06/19/2008 05:11 AM, Michael McMahon wrote:
David,
It was originally intended that the httpserver API would be part of the
platform (actually in the package suggested above) but some members of
the umbrella JSR for jdk 6 didn't agree with including a http serve
Changeset: afcf04c535da
Author:michaelm
Date: 2008-08-21 10:04 -0700
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/afcf04c535da
6258215: Num of backlog in ServerSocket(int, int) should be mentioned more
explicitly
Summary: updated javadoc
Reviewed-by: chegar
! src/share/classes
Changeset: c7fae5013939
Author:michaelm
Date: 2008-09-19 13:32 +0100
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/c7fae5013939
6750364: Error in test for 6744329
Reviewed-by: chegar
! test/com/sun/net/httpserver/bugs/B6744329.java
Changeset: e57447118235
Author:michaelm
Da
Changeset: abf3e1aa8031
Author:michaelm
Date: 2008-09-22 15:53 +0100
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/abf3e1aa8031
6739920: java 6u4~ use larger C heap if there are many threads
Reviewed-by: chegar
! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/sola
701 - 800 of 1041 matches
Mail list logo
