Vyom Tewari | 30 Jun 10:46 2016
Picon

RFR 8151788: NullPointerException from ntlm.Client.type3

Hi All,

Please review the below simple fix.

Bug        : JDK-8151788  NullPointerException from ntlm.Client.type3
Webrev  : 
http://cr.openjdk.java.net/~vtewari/8151788/webrev0.0/index.html 
<http://cr.openjdk.java.net/%7Evtewari/8151788/webrev0.0/index.html>

Thanks,
Vyom

Pavel Rappo | 28 Jun 16:45 2016
Picon

RFR 8160218: HPack decoder fails when processing header in multiple ByteBuffers

Hi,

Could you please review the following change for JDK-8160218?

http://cr.openjdk.java.net/~prappo/8160218/webrev.00/
http://bugs.openjdk.java.net/browse/JDK-8160218

This change addresses two "unrelated" issues that affected decoding of input
data spread across several buffers.

1. An incorrect determining of the final state of string literal decoding in HPACK
2. An incorrect determining of the final buffer in the HttpClient

Thanks,
-Pavel

Langer, Christoph | 23 Jun 16:36 2016
Picon

RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing

Hi,

 

can I please get a review the following change:

Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8160174.1/

Bug: https://bugs.openjdk.java.net/browse/JDK-8160174

 

I made further fixes and cleanups for listing Unix type network interfaces, especially on AIX and Linux. I ran builds and verified also on Solaris and Mac.

 

Thanks

Christoph

 

Sergey Kuksenko | 20 Jun 22:24 2016
Picon

RFR JDK-8158980: Memory leak in HTTP2Connection.streams

Hi,

Could you please review the following fix for JDK-8158980?
http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/

Fix solves the following issue: https://bugs.openjdk.java.net/browse/JDK-8158980

Stream will be never deleted from HTTP2Connection.streams in the following conditions:
1. "content-len" of sending data is zero. e.g. "GET" request.
 in that case "Stream.requestSent" will never be set to true.

2. "Stream.responseReceived" is never set to "true" when used following BodyProcessors (asByteArray, asByteArrayConsumer, asFile, asFileDownload, asString).

Removing Stream from HTTP2Connection requires both fields set to true, so failing normal setting only one of this fields causes memory leak.

The issue is easily reproduces - simple loop with GET request via HTTP/2 leads to OutOfMemoryError.


Sergey Kuksenko | 20 Jun 22:37 2016
Picon

RFR JDK-8158980: Memory leak in HTTP2Connection.streams

Hi,

Could you please review the following fix for JDK-8158980?
http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/

Fix solves the following issue: 
https://bugs.openjdk.java.net/browse/JDK-8158980

Stream will be never deleted from HTTP2Connection.streams in the 
following conditions:
1. "content-len" of sending data is zero. e.g. "GET" request.
  in that case "Stream.requestSent" will never be set to true.

2. "Stream.responseReceived" is never set to "true" when used following 
BodyProcessors (asByteArray, asByteArrayConsumer, asFile, 
asFileDownload, asString).

Removing Stream from HTTP2Connection requires both fields set to true, 
so failing normal setting only one of this fields causes memory leak.

The issue is easily reproduces - simple loop with GET request via HTTP/2 
leads to OutOfMemoryError.

Sergey Kuksenko | 20 Jun 22:36 2016
Picon

RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

Hi,

Could you please review the following fix for JDK-8158690?

http://cr.openjdk.java.net/~skuksenko/jep110/8158690/webrev.00/

Fix solves the following issue: 
https://bugs.openjdk.java.net/browse/JDK-8158690

Peter Firmstone | 19 Jun 13:00 2016
Picon

Secure Java Serialization - validation of untrusted data

 
Historically Java's strong type system has eliminated many security issues developers experience in
other non type safe languages.

De Serialization of untrusted / unvalidated data presents a problem for java, given the deployed software
in use today.

I have a working reimplimentation of deserialization, it is has a subset of the functionality of
Objectinputstream, sufficient for RMI, but it lacks support for circular object graphs and requires
periodical stream resets, or it will throw an IOException, returning control to the caller to prevent
DOS.  Failure is atomic, the first object that cannot satisfy it's invarients is not created and control
returns to the caller.  Every class ProtectionDomain is on the stack at construction, preventing
deserialization into privileged context.  A permission check is also performed prior to construction
on each class in the hierarchy of the serialized object, allowing domain level white listing.

I believe it would be useful to create a superclass of Objectinputstream with this functionality.

Regards,

Peter.

Sent from my Samsung device.
 

 
Historically Java's strong type system has eliminated many security issues developers experience in other non type safe languages.

De Serialization of untrusted / unvalidated data presents a problem for java, given the deployed software in use today.

I have a working reimplimentation of deserialization, it is has a subset of the functionality of Objectinputstream, sufficient for RMI, but it lacks support for circular object graphs and requires periodical stream resets, or it will throw an IOException, returning control to the caller to prevent DOS.  Failure is atomic, the first object that cannot satisfy it's invarients is not created and control returns to the caller.  Every class ProtectionDomain is on the stack at construction, preventing deserialization into privileged context.  A permission check is also performed prior to construction on each class in the hierarchy of the serialized object, allowing domain level white listing.

I believe it would be useful to create a superclass of Objectinputstream with this functionality.

Regards,

Peter.

Sent from my Samsung device.
 
Pavel Rappo | 17 Jun 17:15 2016
Picon

Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

Hi,

Could you please [*] review the following change for the upcoming JDK-8159053?
This change addresses:

1. Listener.onClose/onPing behaviour, making the implementation fully*
responsible of protocol compliance. So reactions on onClose/onPing cannot be
overridden/redefined in a Listener

2. Simpler representation of the Close message.

    /**
     * Receives a Pong message.
     *
     * <p> A Pong message may be unsolicited or may be received in response
     * to a previously sent Ping. In the latter case, the contents of the
     * Pong is identical to the originating Ping.
     *
     * <p> The message will consist of not more than { <at> code 125} bytes:
     * { <at> code message.remaining() <= 125}.
     *
     * <p> The { <at> code onPong} method is invoked zero or more times in
     * between { <at> code onOpen} and ({ <at> code onClose} or { <at> code onError}).
     *
     * <p> If an exception is thrown from this method or the returned { <at> code
     * CompletionStage} completes exceptionally, then { <at> link
     * #onError(WebSocket, Throwable) onError} will be invoked with this
     * exception.
     *
     *  <at> implSpec The default implementation behaves as if:
     *
     * <pre>{ <at> code
     *     webSocket.request(1);
     *     return CompletableFuture.completedStage(null);
     * }</pre>
     *
     *  <at> param webSocket
     *         the WebSocket
     *  <at> param message
     *         the message
     *
     *  <at> return a CompletionStage that completes when the message processing
     * is done; or { <at> code null} if already done
     */
    default CompletionStage<?> onPong(WebSocket webSocket,
                                      ByteBuffer message) {
        webSocket.request(1);
        return null;
    }

    /**
     * Receives a Close message.
     *
     * <p> Once a Close message is received, the server will not send any
     * more messages.
     *
     * <p> A Close message consists of a status code and a reason for
     * closing. The status code is an integer in the range { <at> code 1000 <=
     * code <= 65535}. The reason is a short string that has an UTF-8
     * representation not longer than { <at> code 123} bytes.
     *
     * <p> For more information on status codes and reasons see
     * <a href="https://tools.ietf.org/html/rfc6455#section-7.4">RFC 6455, 7.4. Status Codes</a>.
     *
     * <p> { <at> code onClose} is the last invocation on the { <at> code Listener}.
     * It is invoked at most once, but after { <at> code onOpen}. If an exception
     * is thrown from this method, it is ignored.
     *
     * <p> After a Close message has been received, the implementation will
     * close the connection automatically. However, the client is allowed to
     * finish sending the current sequence of partial message first. To
     * facilitate it, the WebSocket implementation expects this method to
     * return a { <at> code CompletionStage}. The implementation then will
     * attempt to close the connection at the earliest of, either the
     * completion of the returned { <at> code CompletionStage} or the last part
     * of the current message has been sent.
     *
     *  <at> implSpec The default implementation behaves as if:
     *
     * <pre>{ <at> code
     *     return CompletableFuture.completedStage(null);
     * }</pre>
     *
     *  <at> param webSocket
     *         the WebSocket
     *  <at> param statusCode
     *         the status code
     *  <at> param reason
     *         the reason
     *
     *  <at> return a CompletionStage that when completed will trigger closing of
     * the WebSocket
     */
    default CompletionStage<?> onClose(WebSocket webSocket,
                                       int statusCode,
                                       String reason) {
        return null;
    }

    /**
     * Sends a Close message with the given status code and the reason.
     *
     * <p> Returns a { <at> code CompletableFuture<WebSocket>} which completes
     * normally when the message has been sent or completes exceptionally if an
     * error occurs.
     *
     * <p> The { <at> code statusCode} is an integer in the range { <at> code 1000 <= code
     * <= 4999}, except for { <at> code 1004}, { <at> code 1005}, { <at> code 1006} and { <at> code
     * 1015}. The { <at> code reason} is a short string that must have an UTF-8
     * representation not longer than { <at> code 123} bytes.
     *
     * <p> For more information about status codes see
     * <a href="https://tools.ietf.org/html/rfc6455#section-7.4">RFC 6455, 7.4. Status Codes</a>.)
     *
     * <p> If a Close message has been already sent or the { <at> code WebSocket} is
     * closed, then invoking this method has no effect and returned { <at> code
     * CompletableFuture} completes normally.
     *
     * <p> The returned { <at> code CompletableFuture} can complete exceptionally
     * with:
     * <ul>
     * <li> { <at> link IOException}
     *          if an I/O error occurs during this operation
     * </ul>
     *
     *  <at> param statusCode
     *         the status code
     *  <at> param reason
     *         the reason
     *
     *  <at> return a CompletableFuture with this WebSocket
     *
     *  <at> throws IllegalArgumentException
     *         if the { <at> code statusCode} has an illegal value, or
     *         { <at> code reason} doesn't have an UTF-8 representation not longer
     *         than { <at> code 123} bytes
     *
     *  <at> see #sendClose()
     */
    CompletableFuture<WebSocket> sendClose(int statusCode, String reason);

    /**
     * Sends an empty Close message.
     *
     * <p> Returns a { <at> code CompletableFuture<WebSocket>} which completes
     * normally when the message has been sent or completes exceptionally if an
     * error occurs.
     *
     * <p> If a Close message has been already sent or the { <at> code WebSocket} is
     * closed, then invoking this method has no effect and returned { <at> code
     * CompletableFuture} completes normally.
     *
     * <p> The returned { <at> code CompletableFuture} can complete exceptionally
     * with:
     * <ul>
     * <li> { <at> link IOException}
     *          if an I/O error occurs during this operation
     * </ul>
     *
     *  <at> return a CompletableFuture with this WebSocket
     */
    CompletableFuture<WebSocket> sendClose();

Thanks,
-Pavel

--------------------------------------------------------------------------------
[1] Please excuse me for not publishing this in a form of a webrev. The reason
is that currently there are too many outstanding changes in the queue that would
simply obscure the review.
Claes Redestad | 17 Jun 15:43 2016
Picon

RFR: 8159745: Remove java.net.Parts

Hi,

URL.java defines a package-private class Parts, which can be trivially 
inlined in the one place where it's currently used.

Webrev: http://cr.openjdk.java.net/~redestad/8159745/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8159745

Thanks!

/Claes

Chris Hegarty | 16 Jun 17:03 2016
Picon

RFR [9] 8157166: Update spec to account for platforms that do not support multicast

Some platforms do not support multicasting, but the current spec requires that
it is supported. It seems reasonable to relax this, somewhat, so that multicasting
is effectively optional on these platforms. 

java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join
method specifications should be updated to indicate that an exception will be
thrown if invoked on a platform that does not support multicasting.

http://cr.openjdk.java.net/~chegar/8157166/
https://bugs.openjdk.java.net/browse/JDK-8157166

-Chris.

Chris Hegarty | 15 Jun 14:50 2016
Picon

RFR [9] 8157045: NPE during websocket communication with wss

8157045 [1] is blocking folks doing test development for WebSockets. I would
like to push this “temporary” change, to unblock them, until we can refactor some
of this area to fix what appears to be a more significant issue ( readImpl(ByteBuffer)
can read bytes into a different ByteBuffer, but has no way of communicating that
to the caller ). I added asserts to catch this, for now.

http://cr.openjdk.java.net/~chegar/8157045/

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8157045


Gmane