Re: WebSocket client API
Hi, Here's an update on the WebSocket API. This iteration tries to address all issues have been discussed so far: webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.01/ javadoc: http://cr.openjdk.java.net/~prappo/8087113/javadoc.01/ Main differences from the previous version: * Extension support has been postponed and remains an open issue [1] * WebSocket.Builder now also accepts HttpRequest.Builder (for providing custom opening handshake headers) * Outgoing is gone, instead a user can send incomplete Binary and Text messages with ByteBuffers and CharSequences directly * Incoming is gone, instead WebSocket.Builder provides a handler assigning method per event (message or error) * Async methods take a custom context object and a potentially reusable completion handler (NIO2 style) * The API is now j.u.c.Flow-friendly --- [1] https://bugs.openjdk.java.net/browse/JDK-8138949; That doesn't mean the default implementation won't support 'permessage-deflate'. -Pavel > On 31 Aug 2015, at 15:30, Pavel Rappo wrote: > > Hi, > > I would appreciate if you help to review a WebSocket client API proposed for > JDK 9. This work is a part of JEP-110 [1] and has started its public path with > HTTP client review in March this year [2]. > > Proposed WebSocket API is relatively small and focuses on convenient exchange > of > data in a fully asynchronous fashion. API consists of 6 types located in the > java.net package [3]: > > 1. WebSocket > 2. WebSocket.Builder > 3. WebSocket.Incoming > 4. WebSocket.Incoming.Chunks > 5. WebSocket.Outgoing > 6. WebSocketException > > Starting point is a class description for java.net.WebSocket. Along with > in-javadoc examples, several API test samples are provided in the webrev [4] > and > named test/java/net/WebSocket/Example%.java. They are only for informational > purposes and won't be included in the final version of the API. > > I would appreciate any feedback on this API. Thanks. > > --- > [1] http://openjdk.java.net/jeps/110 > [2] http://mail.openjdk.java.net/pipermail/net-dev/2015-March/008932.html > [3] http://cr.openjdk.java.net/~prappo/8087113/javadoc.00/ > [4] http://cr.openjdk.java.net/~prappo/8087113/webrev.00/ > > -Pavel
RFR: JDK-8022748 (new URI(u.toString()).equals(u), does not hold with paths containing colons
Hi, i investigated the problem described in JDK-8022748[1] i found that the parser needed to be rescued for confusion while handling relative URIs. A URI created through the relativize-method is schemaless and so it need to handle the special-case (a colon in the path-element). While there is also another way to handle it (encode the colon as %3A) i think we should not choose to encode everything. First it would introduce another style of special-case handling of a colon in the path (see the method maybeAddLeadingDot which is used while normalizing) and when resolving it back we would need to decode it back or leave it the encoded way which is not suggest by RFC2396 section "1.5 URI Transcribability". Also in Section 5 of RFC2396 it is suggested to rescue a colon in the path-element in a relative URI through prepending a "./" just like in maybeAddLeadingDot. I am not sure if it is worth to refactor the split(),join(),normalize() methods to provide a reusable colon-detection and -handling. So, please find my webrev with a simpler solution at: http://cr.openjdk.java.net/~sebastian/8022748/webrev.00/ -- Sebastian [1] https://bugs.openjdk.java.net/browse/JDK-8022748
Re: TLS ALPN Proposal v7
I didn't reply on this last week, but this looks workable to me. Thanks! On 10/02/2015 07:19 PM, Bradford Wetmore wrote: On 10/1/2015 7:35 PM, Xuelei Fan wrote: On 10/2/2015 9:03 AM, Bradford Wetmore wrote: Major changes: 1. ApplicationProtocols is gone. The H2 black list and comparator were moved to StandardConstants. 2. StandardConstants. Strings for "h2" and "http/1.1" are back. And now that you are parsing the raw network bytes, I added a convenience mapping between the two byte ciphersuite IANA-assigned value and the Java Standard Name. There is no SSLExplorer in OpenJDK. I think, maybe, the map is not belong to OpenJDK either. I think, the constants for HTTP2 is also belong to application protocol (HTTP2) layer. Application (HTTP2) implementation would take care of them. Maybe, they are not a part of JSSE framework either. Ok, I've removed all of the H2 constants from StandardConstants. I've mentioned to the the H2/network team that this is something they will need to handle/include (e.g. Blacklist/Comparator) in their code, and they might want to consider APIs similar to what I had. I personally found it very useful to have a proper mapping to get the SSL_ vs. TLS_ prefix correct in the blacklist. I would like to have "h2" and "http/1.1" defined as Standard Algorithms Docs as we usually did for other standard constants. Of course, they will be added as Standard Algorithm names. 3. SSLParameter (set/get) are moved to SSLSocket/SSLEngine. Even though these could go into SSLParameters, this change makes backporting much easier. The helper code simply has to reflectively look for the four methods in the implementation classes, and call if they are there. Otherwise, there would have to be reflection both in the user code (above) and implementation (to see if the passed SSLParameters had the new methods via a subclass). But, looking forward, per JSSE framework, SSLParameters should be the central place to define SSL/TLS configuration parameters. We'd better follow the conventions so that application developers won't get confused about where SSL/TLS parameters should be configured. I went back and forth on this many, many times yesterday. Maybe, we cannot add public APIs for backporting. I figured we'd have to use reflection on user-derived classes to see if the methods were there, but apparently implementation-specifc APIs can be added in an update release, just not Java APIs. So if we really can do that, then we can add a jdk.SSLParameters/ org.openjdk.jsse.SSLParameters extends SSLParameters, and in the implementation, look for instanceof. I think backporting is another history, and would better not impact too much of the design for JDK 9 and future releases. Ok, so get/setApplicationProtocols() is back in SSLParameters. Thanks for the comments everyone. I'm submitting the following to the CCC (internal review board): http://cr.openjdk.java.net/~wetmore/8051498/webrev.17/ Changes: 1. No H2 Blacklist/Comparator 2. set/getApplicationProtocols() back to SSLParameters. Thanks, Brad -- - DML
Re: WebSocket client API
Hi, Overall i think this API seems to be compressing down nicely to a small number of classes/interfaces, but i still think there is some room for further simplifications. WebSocket I don’t see the need for a context parameter. Context can be obtained via capturing. That reduces the requirement for a specific but generic BiHandler, since a BiConsumer could be used instead. A null completion handler could be allowed for those not interested in completion events. My preferred alternative to the callback handler approach is to return a Completable that completes with the WebSocket instance or exceptionally. That to me better fits with the notion of completion of a specific event (just like that when async building a connected WebSocket), that allows one to chain off events or even block if necessary. It also reduces the need for a specific but generic functional interface. I suspect the common case would be to ignore the CF that is returned. WebSocket.Builder The protocol of receiving events is spread out over multiple behavioural parameters. Instead we could have a functional interface, WebSocketMessageListener say, with defaults for all but the most common event, which i guess is the receiving of text messages. It’s easy to reintroduce the current behaviour as a separate layer if so desired e.g. a simple message event builder, but it’s really awkward to do it the other way around, which is a design smell to me. The builder can then be reformulated as: Builder(String uri) // A URI is the only required argument using(HttpClient ) // Overrides any previous call using(HttpRequest.Builder ) // Overrides any previous call subprotocols(String , String ...) listener(WebSocketMessageListener ) // Overrides any previous call WebSocket build( ) CF buildAsync() The end result is WebSocket.BiHandler/Handler go away to be replaced with one specific web socket message listener interface whose documentation describes the receiving protocol and the threading/concurrency callback behaviour, and overall there is a simplification in the set of methods and their signatures. Paul. > On 6 Oct 2015, at 12:27, Pavel Rappo wrote: > > Hi, > > Here's an update on the WebSocket API. This iteration tries to address all > issues have been discussed so far: > > webrev: http://cr.openjdk.java.net/~prappo/8087113/webrev.01/ > javadoc: http://cr.openjdk.java.net/~prappo/8087113/javadoc.01/ > > Main differences from the previous version: > > * Extension support has been postponed and remains an open issue [1] > * WebSocket.Builder now also accepts HttpRequest.Builder (for providing > custom opening handshake headers) > * Outgoing is gone, instead a user can send incomplete Binary and Text > messages with ByteBuffers and CharSequences directly > * Incoming is gone, instead WebSocket.Builder provides a handler > assigning method per event (message or error) > * Async methods take a custom context object and a potentially reusable > completion handler (NIO2 style) > * The API is now j.u.c.Flow-friendly > > --- > [1] https://bugs.openjdk.java.net/browse/JDK-8138949; >That doesn't mean the default implementation won't support >'permessage-deflate'. > > -Pavel > >> On 31 Aug 2015, at 15:30, Pavel Rappo wrote: >> >> Hi, >> >> I would appreciate if you help to review a WebSocket client API proposed for >> JDK 9. This work is a part of JEP-110 [1] and has started its public path >> with >> HTTP client review in March this year [2]. >> >> Proposed WebSocket API is relatively small and focuses on convenient >> exchange of >> data in a fully asynchronous fashion. API consists of 6 types located in the >> java.net package [3]: >> >> 1. WebSocket >> 2. WebSocket.Builder >> 3. WebSocket.Incoming >> 4. WebSocket.Incoming.Chunks >> 5. WebSocket.Outgoing >> 6. WebSocketException >> >> Starting point is a class description for java.net.WebSocket. Along with >> in-javadoc examples, several API test samples are provided in the webrev [4] >> and >> named test/java/net/WebSocket/Example%.java. They are only for informational >> purposes and won't be included in the final version of the API. >> >> I would appreciate any feedback on this API. Thanks. >> >> --- >> [1] http://openjdk.java.net/jeps/110 >> [2] http://mail.openjdk.java.net/pipermail/net-dev/2015-March/008932.html >> [3] http://cr.openjdk.java.net/~prappo/8087113/javadoc.00/ >> [4] http://cr.openjdk.java.net/~prappo/8087113/webrev.00/ >> >> -Pavel > signature.asc Description: Message signed with OpenPGP using GPGMail
