Re: Adding values to enum java.net.StandardProtocolFamily
On 02/13/2014 07:33 AM, Florian Weimer wrote: On 02/13/2014 02:21 PM, Alan Bateman wrote: On 13/02/2014 12:54, Florian Weimer wrote: Can we add further enumeration values to java.net.StandardProtocolFamily? The spec does not say so, unlike javax.lang.model.SourceVersion, and the code in the JDK expects a binary flag, so I think the answer is "no". Does this mean the expected way to add support for further protocol families would be to create a separate implementation of java.net.ProtocolFamily? If there are protocol families that will be part of Java SE and supported in all implementations then they could be added StandardProtocolFamily. On the other hand, if this is platform or JDK implementation specific then implementing ProtocolFamily is the way to go (the enum extending interface pattern is something that we've used in other areas too). Okay, sounds reasonable. The PF_LOCAL protocol family is not available with Winsock, so I guess it will have to be a separate enum then, with a single member, although OpenJDK already requires PF_LOCAL support on the non-Windows platforms. Windows "named pipes" seem similar enough to UNIX sockets for a uniform implementation (full-duplex, socket-like connection, byte- or message-oriented, reliable delivery, file-like API, to list a few things off of wikipedia). It was my intent to support them in XNIO on Windows at some point, equivalently to UNIX sockets on other OSes, which I already have some support for. For this reason it was always a pet peeve of mine that OpenJDK hasn't gone in for UNIX sockets. -- - DML
Re: TLS ALPN Proposal v5
On 09/25/2015 06:42 AM, Simone Bordet wrote: Hi, On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan wrote: Here is the question to answer, which preference should be respected firstly between cipher suite and application protocol? If application protocol are preferred at first, of course, application preference should be respected at first; otherwise, cipher suite preference should be respected at first. The answer to this question has been decided when the algorithm has been chosen to be: for each cipher for each application protocol end end All the rest being equal, ciphers dominate application protocol selection. Are you suggesting to change this to: for each application protocol for each cipher end end ? It's in the hands of the role that configures application protocols and ciphers to decide whether it's more important to prefer a protocol or a cipher. I agree with this, but... Put it in a different way: If the role prefers application protocols, it has to sort the ciphers to influence that. If the role prefers ciphers, it has to sort the ciphers. No matter what, it has to sort the ciphers. ...why does sorting even matter? Why should selection not be implemented 100% in user code, based on both the cipher suites list and application protocol, rendering this whole discussion pointless? It's clearly a complex enough process (which is highly protocol-specific) that it seems to me quite unlikely that the JDK can possibly implement this in a way that will work for all use cases. Therefore, personally, I think application may want a handy tool to sort the cipher suite for the strength for general purpose, but not for application protocol. Because HTTP/2 would probably be popular given the success of its predecessor, it would be handy to have a HTTP/2 comparator to influence the selection of the HTTP/2 protocol. Nothing forbids to offer a comparator by cipher strength too. Ugh, why not just let the user decide *if* they want to sort (and filter) ciphers, and if so, they can do it themselves using Arrays.sort() on the ciphers array which already should be more than adequate. In fact, why not just use the SSLExplorer approach and be done with this already? -- - DML
Re: TLS ALPN Proposal v5
On 09/25/2015 07:29 AM, Simone Bordet wrote: Hi, On Fri, Sep 25, 2015 at 2:15 PM, David M. Lloyd wrote: ...why does sorting even matter? Why should selection not be implemented 100% in user code, based on both the cipher suites list and application protocol, rendering this whole discussion pointless? It's clearly a complex enough process (which is highly protocol-specific) that it seems to me quite unlikely that the JDK can possibly implement this in a way that will work for all use cases. Bradford can certainly provide more context here, but the "tuple selection" approach would have required a (large) rewrite of the current mechanism, and it was discarded because of resource constraints. In fact, why not just use the SSLExplorer approach and be done with this already? You mean this ? http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sni/SSLExplorer.java Can you expand on how such approach would look like ? Seems overkill to me, and all in the hands of application developers ? Well, SNI already basically works this way, so it's not so great a stretch. I imagine the client code simply specifying a list of protocols along with today's list of cipher suites. The user-space server side logic would go like this: * Receive SSL ServerHello * Examine the packet for ALPN and SNI information * Read the list of cipher suites * Evaluate * Select an SSLContext based on protocol and/or server name * Construct an SSLSocket or SSLEngine as appropriate * Set a property on the SSLSocket/SSLEngine to indicate ALPN protocol name * (optional) Change/sort the cipher suite list on the SSLSocket/SSLEngine as appropriate * Resume negotation by passing the ServerHello in to the SSLSocket/SSLEngine as initial data It's not super elegant but it should work just as well as SNI works, and it would cover 100% of use cases since the user has complete flexibility to make a decision based on any combination of cipher suite selection, protocol name, and host name, even potentially with the option to pretend that ALPN wasn't recognized. -- - DML
Re: TLS ALPN Proposal v5
Sorry I didn't get the reply from Simone Bordet - it must have gone to only one of the two lists (which I'm not on). On 9/25/2015 9:14 PM, Simone Bordet wrote: I don't follow ? SNI has APIs in JDK 8, you don't use SSLExplorer at all. They're highly limited; you can only tell the socket/engine to accept or reject a connection based on the SNI information. The ability to react to the server name in order to configure other parameters is highly limited, let alone being able to do things like select a different SSLContext altogether, or proxy the connection to another host. Also, SNI is a client-to-server information only, while with ALPN you have to reply to the client, so you have to modify the ServerHello. I don't see how you can do this without support from the JDK via APIs ? Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine to specify the selected protocol; this would be done during setup before you initiate handshake (which is why you need to explore the Hello packet in the first place). Better to start simple in any event. With this one single method change, we *could* have a 100% effective solution for all use cases. There could be a fancier solution later, when time isn't ticking towards a JDK 9 deadline. Are you saying that every application has to write its own TLS parser ? Every *server* application, yes, though most users will rely on a security or server library to do this already. Of course we could always add an SSLExplorer-like function to the JSSE API - that would be very nice - but the point of this suggestion is to keep things realistic and get the job *done*. Would not that be overkill and full of potential security issues if one does not get the implementation strictly correct ? Nah, you don't have to do much other than look in the hello packet, make a decision, and then hand it off to the SSL context, which would then do a much more rigorous validation. I don't think there's much risk here. Also, what if the JDK implementation refuses to use the cipher you chose along with the application protocol, for whatever reason ? Then you'd get an alert, I'd expect. But my point is that it's not the JDK's business to introspect the application protocol! The JDK should only be looking at (TLS) protocol and cipher suite as it does today. It's up to the application protocol to determine if there are unacceptable cipher suites for that protocol. Any other approach is inherently broken! What if I add a new application protocol, and some cipher suites are unacceptable for it? Should I just rely on the JDK for half the time? Definitely not - the protocol implementation *must* be fully responsible for its own security policy. On 09/25/2015 09:19 AM, Xuelei Fan wrote: There are two typical cases for SNI and ALPN. One is that the same server is used for difference SNI/ALPN. Another one is that different server is used for different SNI/ALPN. For example, there is a TLS server 101.101.1.1 for delegation. If SNI www.example.com get requested, the delegation server may redirect the connection to 192.168.1.100 (provide the service for www.example.com). If SNI www.another.com get requested, the delegation server may redirect the connection to 192.168.1.101 (provide the service for www.another.com). Similarly, ALPN need to support the case as above. Another example, there is a server 101.101.1.1. If SNI www.example.com get requested, the server would act as the service for www.example.com. If SNI www.another.com get requested, the server would act as the service for www.another.com. Similarly, ALPN also need to support the case as above. Exactly - you may want or need to choose different SSL contexts, or even forward to another host, based on this information. Relying solely on SNIMatcher (for example) is already not adequate by itself for many use cases. Consider also that we're talking about server side code here: the number of potential users is small! I believe that end users will only indirectly use this mechanism through server frameworks, meaning that only the framework authors are really the direct consumers. -- - DML
Re: TLS ALPN Proposal v5
On 09/25/2015 10:13 AM, Simone Bordet wrote: Hi, On Fri, Sep 25, 2015 at 4:48 PM, David M. Lloyd wrote: Yes, you would have to add a method - *one* method - to SSLSocket/SSLEngine to specify the selected protocol; this would be done during setup before you initiate handshake (which is why you need to explore the Hello packet in the first place). You also need to add another method to specify the cipher suite that goes along with the application protocol. No you wouldn't, because there already is a method for that: setEnabledCipherSuites(). You can only send one protocol back in the response, so there's nothing else to do. Matching suites to protocols is the responsibility of the application protocol developer and must be done before handshake. We have already discussed this approach: it's the "tuple" approach where the application is given the list of TLS protocols, the list of ciphers, the list of application protocols, the list of aliases and decides what is the right tuple, and return that to the JDK. Also, what if the JDK implementation refuses to use the cipher you chose along with the application protocol, for whatever reason ? Then you'd get an alert, I'd expect. That would be wrong, because you could actually speak another protocol. If you could, then the server would have chosen another protocol before handshake even begins. But my point is that it's not the JDK's business to introspect the application protocol! The JDK should only be looking at (TLS) protocol and cipher suite as it does today. It's up to the application protocol to determine if there are unacceptable cipher suites for that protocol. Any other approach is inherently broken! What if I add a new application protocol, and some cipher suites are unacceptable for it? Should I just rely on the JDK for half the time? Definitely not - the protocol implementation *must* be fully responsible for its own security policy. I don't understand where you got the impression that the JDK has to inspect the application protocol. We are discussing an API exposed by the JDK to applications, exactly because the application decides whether to accept or not the combination of application protocol, cipher, etc. Yes, but doing so by SSLContext is already too late in many cases. Trying to make a hook into handshaking is the wrong way of looking at this. The user needs to make decisions *before* handshaking is even initiated on the server. -- - DML
Re: TLS ALPN Proposal v5
On 09/25/2015 11:37 AM, Simone Bordet wrote: David, sorry, but I don't understand your proposal. Can you please write it down in pseudo code what a server application should do and what the JDK should do to negotiate HTTP/2 with a client ? Sure. A: receive raw SSL packet on Socket or SocketChannel A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info A: either proxy the connection, or obtain or create the relevant SSLContext from the desired provider A: construct server-side SSLSocket/SSLEngine from SSLContext A: setApplicationProtocol(H2) A: setEnabledCipherSuites(only allowed suites in desired order) A: start handshake J: receive ClientHello (buffered from A) J: verify SNI is matched, fail otherwise (as today) J: verify ALPN is matched, fail otherwise (new) J: send ServerHello (with the single, user-selected protocol) ... This is very simple from the JDK perspective, and also much more flexible. I don't see how it is even possible for a user to decide anything *before* the handshaking is even initiated, like you say. It obviously does not have enough information. It has the ClientHello, which should be more than enough. This is the current algorithm (A=app code, J=JDK code): A: sslParameters.setApplicationProtocols(H2, H1); A: (optional, only needed for H2) sort ciphers to favor H2 A: start handshake J: receive ClientHello J: ciphers = intersect client/server ciphers J: aps = intersect client/server application protocols J: for each cipher in ciphers J:for each ap in aps J:if (ap.matches(cipher & other info)) break J end // aps [A: ap.matches() calls into application code to return whether ap is good for the given info] J:if (ap was not selected) continue; // to next cipher J:if (trySetCipherSuite(cipher)) break; // success J: end // ciphers J: send ServerHello J: terminate handshake A: sslEngine/sslSocket.getApplicationProtocol() So complex! What if this algorithm is not adequate for new protocols? Is there not a danger associated with assuming HTTP/2 is your only use case? What if the application wants to make a decision that this scheme cannot support? Note that the JDK provides default implementations for H1 and H2 for ap.matches(), but in general these will be implemented by application code. For an application that wants to support H2, this boils down to the first 2 lines, the rest is in the JDK. -- - DML
Re: TLS ALPN Proposal v5
On 09/25/2015 12:13 PM, Simone Bordet wrote: Hi, On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote: A: receive raw SSL packet on Socket or SocketChannel A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info This requires the application to write a TLS parser. This is currently not necessary, nor provided. It is already necessary to make many non-trivial SNI decisions. I don't see ALPN as deserving higher treatment than SNI. You think this could be provided via a JDK utility class ? And if so, how can it be extended in the future when more TLS Extensions are defined ? I don't think it's necessary, no. A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info The application must intersect the ciphers, application protocols... perhaps again this can be done by some JDK utility class. The point of the approach is that it is unlikely that any JDK-driven logic will be adequate for all use cases. It's better to let the application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN protocol, one SNI name, only valid ciphers. A: either proxy the connection, or obtain or create the relevant SSLContext from the desired provider A: construct server-side SSLSocket/SSLEngine from SSLContext A: setApplicationProtocol(H2) A: setEnabledCipherSuites(only allowed suites in desired order) A: start handshake J: receive ClientHello (buffered from A) J: verify SNI is matched, fail otherwise (as today) J: verify ALPN is matched, fail otherwise (new) There is a missing step here which is to verify the cipher (trySetCipherSuite() logic). The application protocol implementation chooses only valid cipher suites for the protocol. Why would it choose one that is not valid, considering that the protocol implementation itself is the only thing that "knows" what is valid or not? If that fails then we must try another application protocol. We cannot just fail the connection. How do we go from here to the top again to choose another protocol ? J: send ServerHello (with the single, user-selected protocol) ... This is very simple from the JDK perspective, and also much more flexible. Well, I kinda like it, but I have strong reservations that it cannot really "negotiate" the application protocol, meaning that if one application protocol fails, try the next, and then the next and so forth until one succeeds (or they all fail). This validation should have happened before the JDK ever has a chance to be involved. -- - DML
Re: TLS ALPN Proposal v5
Here are some solid reasons that this is the best possible approach: * It will work for 100% of foreseeable use cases - i.e. there is 0% risk of permanently baking in flawed logic into the API * It is dead simple - only one new method on SSLSocket/SSLEngine to set the protocol list (client) or selected single protocol (server) * Because it is dead simple, it should be very easy to backport to Java 8 *Example 1*: Add a static org.openjdk.jsse.ALPN#setApplicationProtocol(SSLEngine | SSLSocket s, String[] protocols) method, which calls (maybe even reflectively?) the setApplicationProtocol() method on the SSLEngine/SSLSocket implementation if it is present & public *Example 2*: Add an org.openjdk.jsse.ALPNAware interface with the setApplicationProtocol(String[]) method, which is implemented by JSSE providers * Now Java EE 8 can trivially achieve HTTP/2.0 support with very low risk to either the JDK/SE timeline or the EE timeline * Since most or all of the "hard" logic is on the server side, the majority of API consumers will have an easy time using the API * We server developers can handle the rest! On 09/25/2015 12:23 PM, David M. Lloyd wrote: On 09/25/2015 12:13 PM, Simone Bordet wrote: Hi, On Fri, Sep 25, 2015 at 6:49 PM, David M. Lloyd wrote: A: receive raw SSL packet on Socket or SocketChannel A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info This requires the application to write a TLS parser. This is currently not necessary, nor provided. It is already necessary to make many non-trivial SNI decisions. I don't see ALPN as deserving higher treatment than SNI. You think this could be provided via a JDK utility class ? And if so, how can it be extended in the future when more TLS Extensions are defined ? I don't think it's necessary, no. A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info The application must intersect the ciphers, application protocols... perhaps again this can be done by some JDK utility class. The point of the approach is that it is unlikely that any JDK-driven logic will be adequate for all use cases. It's better to let the application be a black box: ALPN+SNI+Ciphers -> app logic -> one ALPN protocol, one SNI name, only valid ciphers. A: either proxy the connection, or obtain or create the relevant SSLContext from the desired provider A: construct server-side SSLSocket/SSLEngine from SSLContext A: setApplicationProtocol(H2) A: setEnabledCipherSuites(only allowed suites in desired order) A: start handshake J: receive ClientHello (buffered from A) J: verify SNI is matched, fail otherwise (as today) J: verify ALPN is matched, fail otherwise (new) There is a missing step here which is to verify the cipher (trySetCipherSuite() logic). The application protocol implementation chooses only valid cipher suites for the protocol. Why would it choose one that is not valid, considering that the protocol implementation itself is the only thing that "knows" what is valid or not? If that fails then we must try another application protocol. We cannot just fail the connection. How do we go from here to the top again to choose another protocol ? J: send ServerHello (with the single, user-selected protocol) ... This is very simple from the JDK perspective, and also much more flexible. Well, I kinda like it, but I have strong reservations that it cannot really "negotiate" the application protocol, meaning that if one application protocol fails, try the next, and then the next and so forth until one succeeds (or they all fail). This validation should have happened before the JDK ever has a chance to be involved. -- - DML
Re: TLS ALPN Proposal v5
On 09/25/2015 02:11 PM, Simone Bordet wrote: Hi, On Fri, Sep 25, 2015 at 7:23 PM, David M. Lloyd wrote: The application protocol implementation chooses only valid cipher suites for the protocol. Why would it choose one that is not valid, considering that the protocol implementation itself is the only thing that "knows" what is valid or not? The cipher could fail for the number of reasons it fails in trySetCipherSuite(), even if the application has chosen the right combination of (application protocol, cipher, whatever else). At that point you have to try another application protocol. From my reading of that code, it can only fail if you specifically set up invalid combinations of cipher suite, protocol, and credentials. The application code should have all the information it needs to set up a correct configuration though. This validation should have happened before the JDK ever has a chance to be involved. See above. Unless it is verified that trySetCipherSuite() cannot *ever* fail after a cipher has been chosen (but then the method should return void), then I don't see how your proposal could work. The method isn't magical; it is just working off of known inputs. If you give inputs that will ultimately result in a correct negotiation (and nothing leads me to believe that there is any reason that the application protocol user cannot do this), then you will get a successful output. On the other hand, if (for example) the user selects a cipher suite that is incompatible with their credentials, or which is incompatible with the protocol which the user *also* selected, I don't see any good reason to give them another chance. In other words, you're assuming that the only way to know if a configuration is correct is to try it, but that just isn't true. Have you written an implementation already ? That would help. No. -- - DML
Re: TLS ALPN Proposal v5
Hi Brad, thanks for replying; comments are inline: On 09/28/2015 08:40 PM, Bradford Wetmore wrote: Several comments about David's proposal: 1. Only the initial ClientHellos are parsable. === The biggest problem I have with an Explorer-based design is that only the initial ClientHello on a connection is passed in the clear. Subsequent negotiations on this connection will be completely missed, as the ClientHellos are now encrypted. This seems like a deal breaker for me. You are right, I cannot come up with a good solution for this, so that might mean the idea is shot - *however* - I would point out that the latest draft of TLS 1.3 [1] completely kills off the capability of the client to renegotiate a connection, meaning that this will no longer be possible anyway, and given it's a 1% kind of use case, that might be enough to let it slide. Combine this with what I consider to be the unlikelihood of this working with HTTP/2.0, and I would feel very safe assuming that nobody will ever actually do this. I would also note that, as you state later on, it would be possible to combine this solution with any other solution (including the proposed one) to cover both cases. And given that this is still (in my estimation) a "99%" solution, in my opinion it is still a viable candidate for adding this functionality to Java 8 as a first pass or stopgap as I described in my emails, particularly if the method(s) to establish/query the protocol names are a strict subset of the proposed Java 9 API (given that we cannot really overhaul the Java SE 8 API at this point). [...] 2. "SSLExplorer" or something similar is needed. = This approach depends on "examining SSLClientHello"s, but there isn't a class for this other than some sample code from a previous attempt. I am assuming that this approach would make such an external API a necessity? Being able to parse possible ClientHello formats is not a straightforward/easy job. This will add a fair amount of complexity, and likely not an easy job in the remaining few weeks. It could be added later for JDK 10 but that means apps would likely need to roll their own for 9. And 8, yes, you definitely would need to roll your own, though Xuelei Fan already has a nice example up on his blog that was built for SNI (but uses the same principle). If it were me, I wouldn't even bother adding it even in JDK 10, since (a) it applies only to the server side and (b) there are a plethora of third-party server-side network I/O and security libraries which are natural candidates to host this type of logic. 3. "no_application_protocol" = If the server doesn't support the protocols that the client advertises, the "no_application_protocol" must be thrown. We could add a "no_application_protocol" protocol String that would flag such a condition internally. Sure, though if you use the same method on both the client and server to specify the matched protocol, then the method necessarily accepts an array, in which case a null/unset could mean "no ALPN response" and an empty array could mean "no acceptable protocols". But yeah I agree otherwise. 4. Much of this is already possible. = If we were to go with the current API/internal and apps provided their own ClientHello scanner, many of the benefits of what was proposed are already available. Apps can ask for the desired SSLContext, get the SSLSocket/SSLengine, check the SNI/ALPN values, order/set the enabled protocols/ciphers/etc + single ALPN value, then wrap the raw socket using SSLSocketFactory.createSocket(Socket s, InputStream consumed, boolean autoClose), and start the handshake. The internal code would still call matches() but only once. If you want to be sure the internals select the ApplicationProtocol, just put in a permissive ApplicationProtocol. The API is still more complicated unfortunately as ApplicationProtocol is still present, but the overall behavior is quite similar. +1 yep exactly. I would however turn it around and also say, a more complex API could later be added on top of this simpler proposed solution, especially after more real world data is acquired, which might lower the overall risk as well. 5. Other failure mode/fallback. In the new proposal, suppose you do set a single ALPN value in the application level, and the ServerHandshaker finds some other aspect of the handshake wasn't appropriate (creds were mentioned several times, but maybe a ciphersuite went dark due to new AlgorithmConstraints). This would cause the ServerHandshaker to fail and there's no way to go back to a different version unless you add a "for ALPN" loop into application. Yeah all that validation would have to be done up front or manually in whatever server configuration is relevant. If a cipher suit
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: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor
Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been "eliminate". As such, the interface and service descriptor sun.net.spi.nameservice.NameService sun.net.spi.nameservice.NameServiceDescriptor* *together with its implementation (sun.net.nameservice.dns.DNSNameService) has been remove from the JDK libraries. This is unfortunate. There's really no other way to hook into name resolution. What's wrong with putting this stuff in a com.sun or org.openjdk module? Having modules doesn't *really* require that everything non-standard be hidden or killed off, just that it be separated from the standard modules in a way that makes some kind of sense. -- - DML
Re: Help needed: Java Socket and close detection
I don't think this really makes sense as a place to ask these questions, but I can probably answer them to an extent at least. When a TCP connection is closed normally, the side (we'll call it A) which initiates the close (usually by shutting down the write half of the socket) sends a FIN and enters into the FIN_WAIT_1 state, and the other side (which we'll call B) receives the FIN, entering into the CLOSE_WAIT state. When B receives the FIN, it does two things: it (invisibly) sends an ACK to A, and it reports an end-of-file condition on the socket (resulting in -1 being read in Java, assuming any other unread data is read). When A receives that ACK, it usually transitions from FIN_WAIT_1 to FIN_WAIT_2 (we'll see an exception to that next). Typically once a -1 is read by B, B will shut down the read half and will finish up writing any last bits of data on the socket, and then initiate its own close, shutting down the rest of the socket, causing B to transition from CLOSE_WAIT to LAST_ACK. This causes B to send a FIN back to A, who then receives it and transitions to TIME_WAIT. Note that if all this happens quickly enough, A might get a FIN+ACK before it gets the ACK, causing a direct transition from FIN_WAIT_1 to TIME_WAIT. If A gets the FIN first, it will transition from FIN_WAIT_1 to CLOSING, where it will remain until the final ACK comes, at which point it will move to TIME_WAIT. Any transition to CLOSING or TIME_WAIT will cause the "last ACK" to be sent, which upon receive will cause B to move to the CLOSED state, and allow B to free up the resources associated with the socket. A will remain in TIME_WAIT until a linger timeout expires, at which point the socket will be CLOSED and its resources released. Note that nowhere in this process does an RST come into play. Now when you close a socket "abruptly", for example by closing the read side while the peer is still sending an RST could be generated. This is usually considered a "soft" error condition by the way; you normally shouldn't shut things down that way, but it's probably tolerable most of the time. The exception message in this case is generally "Connection reset by peer", rather than receiving a graceful -1 as you would in the case of receiving a FIN. There are other ways to force RST to be sent, but most applications don't and shouldn't do it. The tricky bit comes in when you have a connection which is idle on both sides. If both sides are then "closed", that is, both read and write halves are shut down at the same time, everything can still happen tidily: a FIN is sent, a FIN is received, and we begin the walk towards the CLOSED state. The problem is that if one side doing a whole-channel close is not aware that the other side is still sending, an RST will result. So to answer your questions in order then: first, an RST can be generated by the network stack for a variety of reasons, but I would not expect well-behaved Java applications to do it normally, unless it's a case of application termination or something along those lines. Second, yes it is normal behavior for RST to not be sent. And third, the JVM does detect FIN packets by reporting an EOF to the read side of the socket (after the read buffer was fully drained); this represents normal application behavior. PS, if you Google for "TCP state diagram", you will find several ways to visualize what I've described above. On 07/13/2016 10:29 AM, Langer, Christoph wrote: Hi folks, I have a question to the experts - regarding an issue that was reported to me by a customer. In the customer scenario they are running a Servlet engine and the Servlet is constantly sending data to a browser client. When the browser client is closed, the server does not get a notification of the other end having been terminated and is constantly sending out data and blocking an application thread. I’m under the assumption that the server should get an RST packet from the network upon writing/flushing data to the OutputStream as soon as the client is gone and hence an Exception should pop up but this isn’t happening. There is a load balancer and maybe other network infrastructure involved in between the Servlet JVM and the browser client. We did some TCPDUMP tracing at the load balancer and we could not see an RST packet coming in from the client side. But when I’m running the scenario without all this network infrastructure involved, e.g. between servers and clients in the same network, I would always observe an RST packet once I close the browser. A FIN packet is received, too, but this does not lead to an Exception and to all my knowledge this can’t be detected, not from the java Socket API and even less from the Servlet API which is just dealing with Streams. So my question to the experts is most of all: Would you agree that an RST packet should be generated in the network and received by the server? Or is it a normal behavior that serv
Re: Introduce IOException subclass for ECONNRESET
On 10/04/2016 03:58 AM, Langer, Christoph wrote:
Hi,
I think I would also support replacing sun.net.ConnectionResetException with a
publicly available java.net.ConnectionResetException that subclasses
java.net.SocketException. But, as Chris mentions. a usage example would be
helpful.
At present you're going to be hard-pressed to find exiting code that
detects a connection reset IOException. The reason is that, while you
*can* search for "Connection reset by peer" in the exception message,
that text varies by platform and, more importantly, by locale. So it is
essentially impossible to detect reliably.
But Norman's use case is dead on: a connection reset happens under
common circumstances. In particular, when a TCP socket is closed by the
peer before the peer has read all pending data, an RST is returned.
This happens very often - when a peer process is terminated for example,
or the peer encounters an unrelated exception and terminates the
connection abruptly, both of which happen very, very commonly in
networked applications. For servers the choice today is to fill the log
with meaningless exception traces or lose potentially more serious
problems (EIO for example is something that almost always indicates Bad
Things).
I also support this proposal.
-Original Message-
From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Chris
Hegarty
Sent: Montag, 12. September 2016 17:07
To: Florian Weimer ; Norman Maurer
; net-dev@openjdk.java.net
Subject: Re: Introduce IOException subclass for ECONNRESET
On 12/09/16 14:50, Florian Weimer wrote:
On 08/23/2016 09:40 AM, Norman Maurer wrote:
Hi all,
I first asked this on nio-dev[0] but was asked to move this over to here:
I wonder if it would be possible to add a new IOException sub-class
for ECONNRESET. Often you receive these errors if a remote peer closed
the connection and you try to read from it while using NIO. This is
very often not really something that concerns people and can just be
handled the same as a “normal close”.
So what are the other cases, where ECONNRESET may occur? What is
equivalent on non-Unix platforms, Windows for example?
>> At the moment the only way to
detect this is to inspect the IOException message which is really
hacky.
Do you have examples of code that does this today?
I wonder if we could not add a special IOException sub-class
for this. Something like:
ConnectionResetException extends IOException {
}
Shouldn't it be a subclass of SocketException?
I think it would have to be a subclass of SocketException too, for
compatibility at least, since that is the type that is thrown
today.
sun.net.ConnectionResetException exists today, but I don't think
that it ever finds its way outside of the implementation. And is
of course not part of Java SE.
-Chris.
--
- DML
Parsing too strict in java.net.URI?
The following statement:
URI uri = URI.create("local:");
fails with an exception like this:
java.lang.IllegalArgumentException: Expected scheme-specific part at
index 6: local:
at java.net.URI.create(URI.java:852)
at
org.jboss.ejb.client.Affinity$LocalAffinity.(Affinity.java:131)
... 32 more
Caused by: java.net.URISyntaxException: Expected scheme-specific part at
index 6: local:
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.failExpecting(URI.java:2854)
at java.net.URI$Parser.parse(URI.java:3057)
at java.net.URI.(URI.java:588)
at java.net.URI.create(URI.java:850)
... 33 more
However AFAICT scheme-only URIs are, while not strictly allowed by RFC
2396 [1], in common usage (for example, "about:" in web browsers).
WDYT?
[1] https://tools.ietf.org/html/rfc2396
--
- DML
Re: Special exception for EMFILE / ENFILE when using sockets.
On 12/05/2016 06:29 AM, Norman Maurer wrote: Hi all, I wonder if it would be possible to add a new public exception time for the situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the same for ServerSocket / Socket) failing because of too many open files. The reason is because especially when acting as a server such an exception may be something you can easily recover from. At there is basically no way to detect if this was the cause of an IOException or not. On unix / linux this are the errno values: [EMFILE] The per-process descriptor table is full. [ENFILE] The system file table is full. For netty we would love to be able to know if this was the case of the problem and if so just stop accepting for a period of time to help the system to recover. What others think about this ? I like the idea, but maybe it should be a general IOException since this same error can happen on file open, selector creation (sometimes), pipe creation, etc. -- - DML
Re: Special exception for EMFILE / ENFILE when using sockets.
If you're already having to turn the native error code into (say) an
enum or something, it's effectively equivalent to just having different
types for every error code. The difference is just like:
try {
...
} catch (IOException e) {
switch (e.getErrorCode()) {
case ECONNRESET: return;
case ENFILE: System.out.println("No file descriptors
remain"); return;
default: throw e; // no idea
}
}
versus:
try {
...
} catch (ConnectionResetException ignored) {
} catch (NoFilesRemainingException e) {
System.out.println("No file descriptors remain");
}
I like the latter better in probably 95%+ of situations.
On 12/06/2016 05:14 AM, Langer, Christoph wrote:
Hi,
I would also support if IOException could be enriched to expose the
native error code. However, the user then would need to evaluate this
code in a platform specific manner. Maybe there could be some
class/interface which would help to translate platform specific error
codes to common constants for common error types.
Best regards
Christoph
*From:*net-dev [mailto:net-dev-boun...@openjdk.java.net] *On Behalf Of
*Bernd Eckenfels
*Sent:* Montag, 5. Dezember 2016 20:09
*To:* net-dev@openjdk.java.net
*Subject:* Re: Special exception for EMFILE / ENFILE when using sockets.
Hello,
I know it is a radical idea, but what about exposing errno value in an
IOException.
I do think that the new ConnectionRefused subtype is helpful, but for
each seldomly occuring error case a dedicated exception is more work
than a one time mapping of native errormcodes to fields.
Gruss
Bernd
--
http://bernd.eckenfels.net
On Mon, Dec 5, 2016 at 7:28 PM +0100, "Norman Maurer"
mailto:norman.mau...@googlemail.com>> wrote:
> Am 05.12.2016 um 18:48 schrieb David M. Lloyd :
>
>> On 12/05/2016 06:29 AM, Norman Maurer wrote:
>> Hi all,
>>
>> I wonder if it would be possible to add a new public exception time for
the situation of an SocketChannel.accept(…) or SocketChannel.open(…) (and the same
for ServerSocket / Socket) failing because of too many open files.
>> The reason is because especially when acting as a server such an
exception may be something you can easily recover from. At there is basically no way
to detect if this was the cause of an IOException or not.
>>
>> On unix / linux this are the errno values:
>>
>> [EMFILE] The per-process descriptor table is full.
>> [ENFILE] The system file table is full.
>>
>> For netty we would love to be able to know if this was the case of the
problem and if so just stop accepting for a period of time to help the system to
recover.
>>
>> What others think about this ?
>
> I like the idea, but maybe it should be a general IOException since this
same error can happen on file open, selector creation (sometimes), pipe creation,
etc.
>
> --
> - DML
Sure that would work for me as well :)
Bye,
Norman
--
- DML
RFR: 8252996: Thread safety problem in java.net.ProxySelector
8252996: Thread safety problem in java.net.ProxySelector - Commit messages: - 8252996: Fix visibility issue in ProxySelector Changes: https://git.openjdk.java.net/jdk/pull/184/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=184&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252996 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/184.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/184/head:pull/184 PR: https://git.openjdk.java.net/jdk/pull/184
Re: RFR: 8252996: Thread safety problem in java.net.ProxySelector
On Thu, 17 Sep 2020 13:04:28 GMT, Daniel Fuchs wrote: >> Seems like an oversight when proxy selector was added > > Hi David, > > I can sponsor this for you - unless you already have a sponsor? > > best regards, > -- daniel No, I do not (though @ChrisHegarty did take a peek at my original ML post). - PR: https://git.openjdk.java.net/jdk/pull/184
Integrated: 8252996: Thread safety problem in java.net.ProxySelector
On Tue, 15 Sep 2020 13:54:14 GMT, David M. Lloyd wrote: > 8252996: Thread safety problem in java.net.ProxySelector This pull request has now been integrated. Changeset: cca3a26e Author: David M. Lloyd Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/cca3a26e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8252996: Thread safety problem in java.net.ProxySelector Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/184
Re: A proposal for a FTP client API
On 05/23/2008 10:20 AM, Jean-Christophe Collet wrote: Hello, I have posted an entry in my blog about the current status of the FTP client API. It contains a quick description of the project as well as a link to the current draft of the API. So if you're interested in that topic go take a look at http://blogs.sun.com/jcc/ As mentioned in the post, feedback is very strongly encouraged. This is going into the java.net package - is there/will there be a JSR for this effort? - DML
Re: A proposal for a FTP client API
On 05/23/2008 10:20 AM, Jean-Christophe Collet wrote: Hello, I have posted an entry in my blog about the current status of the FTP client API. [..] As mentioned in the post, feedback is very strongly encouraged. Some technical feedback: 1) FtpClient should implement java.io.Closeable in my opinion. 2) I also feel that listFiles should stream output. How about returning Iterable instead? It could return a one-time-use Iterator, allowing users to use the extended for-loop syntax if they wish. 3) If this is going into JDK 7 - is there any way to reuse any of the FileSystem stuff from JSR-203? I'm thinking specifically of the way they handle file permissions with FileAttributeViews and so forth, but perhaps there's things which can be reused as well. Guess that's all I've got for now. - DML
Re: Embedded HTTP server
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 original subject of this thread (which has been lost): What about an effort to make a standard web server API in the JDK (javax.net.httpserver perhaps)? I for one would be interested in such an effort, based on the API for com.sun.httpserver. - DML
Re: Embedded HTTP server
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 server API in Java SE. So, it was dropped from the platform. And that is why we put it in com.sun. Makes sense I guess. Personally, I wouldn't have any problem with putting it back in the platform, though presumably this question of whether it blurs the line between Java SE and EE would have to be addressed. For those who care about such things, sure. I don't see any technical reason why that should be an obstacle, since there is no such API in Java EE either. :-) From a technical perspective, I'd really only make one change. Right now, server contexts are registered on the HttpServer directly. It would be nice if, instead of registering contexts, you just register a HttpHandler directly on the HttpServer, which always handles all HTTP requests to that server. Then to provide the context-discrimination function, a ContextHttpHandler could be implemented which implements HttpHandler, and which in turn allows you to register per-context HttpHandlers. This would make it a lot easier to implement, say, virtual hosts. Thoughts? - DML
Re: Embedded HTTP server
On 06/20/2008 06:30 AM, Michael McMahon wrote: From a technical perspective, I'd really only make one change. Right now, server contexts are registered on the HttpServer directly. It would be nice if, instead of registering contexts, you just register a HttpHandler directly on the HttpServer, which always handles all HTTP requests to that server. Then to provide the context-discrimination function, a ContextHttpHandler could be implemented which implements HttpHandler, and which in turn allows you to register per-context HttpHandlers. This would make it a lot easier to implement, say, virtual hosts. You mean a kind of two level handler setup - one for the server, and then others for the contexts? Can you elaborate a bit on the benefits of that. Also, would you use the same HttpHandler type at both levels? Sure. To use virtual hosts for an example, in order to support virtual hosts and have separate contexts for each host, the user must register a / context to catch everything. Then they have to choose a delegate handler based on both the request context *and* the host. By changing the context lookup mechanism to a handler itself, the user can register a handler that sorts based on request host, and then delegates to an instance of the provided context handler. This way the user can reuse the context lookup functionality more easily. Also, this approach would remove a level of indirection in the simple case where there's one handler for all requests to an HttpServer, though this benefit seems less important. So the API change would amount to replacing HttpServer.createContext(*) with HttpServer.setHandler(HttpHandler handler), and introducing a new class, say HttpContextHandler implements HttpHandler which would in turn contain the createContext(*) methods removed from HttpServer. - DML
Re: SCTP for Java
On 08/20/2008 04:37 AM, Alan Bateman wrote: Florian Weimer wrote: : I've been wondering for a while if it is possible (with reasonable additional effort) to add new socket and socket address classes without patching the JDK sources. No, it's not. :-) FWIW, a while back I prototyped an "in tree" solution for SocketChannel. The primary motive was to allow for Sockets Direct Protocol (which uses IP addressing) and Unix Domain Sockets (which required a new SocketAddress type). I disagree here. Just because C has traditionally used struct sockaddr in an overloaded fashion doesn't mean it's a good idea to mirror this on the Java side. - DML
Re: SCTP for Java
On 08/26/2008 09:20 AM, Christopher Hegarty - Sun Microsystems Ireland wrote: On 08/26/08 14:41, David M. Lloyd wrote: On 08/20/2008 04:37 AM, Alan Bateman wrote: FWIW, a while back I prototyped an "in tree" solution for SocketChannel. The primary motive was to allow for Sockets Direct Protocol (which uses IP addressing) and Unix Domain Sockets (which required a new SocketAddress type). I disagree here. Just because C has traditionally used struct sockaddr in an overloaded fashion doesn't mean it's a good idea to mirror this on the Java side. Sorry David, I'm sure what you mean here. Can you please clarify. I just mean, what would be the benefit of using SocketAddress rather than using a String or Path directly? You can avoid the difficulties of extending SocketAddress by simply not using it. - DML
Re: SCTP for Java
On 08/26/2008 11:12 AM, Alan Bateman wrote: David M. Lloyd wrote: : I just mean, what would be the benefit of using SocketAddress rather than using a String or Path directly? You can avoid the difficulties of extending SocketAddress by simply not using it. If the protocol or socket address is specified by String then the implementation would still require to understand the representation so that it can map to the appropriate socket type and domain. Is the concern that applications have a dependency on other SocketAddress types? No, the concern is just that the SocketAddress hierarchy is just kind of broken (the indicators are the fact that it's an empty abstract class, and that anywhere it's used, it's immediately casted to a more specific type). You could change this, but it still seems to me like a kneejerk "make it look like Unix" kind of thing to do. Doing this: UnixSocketChannel.open(String) or similar seems more correct to me. If you go the route of using SocketChannel.open(SocketAddress), for example, now you've got instanceof checks for each socket type. Does this not seem like a so-called "code smell" to you? - DML
Re: SCTP for Java
On 08/27/2008 03:00 PM, Florian Weimer wrote: * David M. Lloyd: Doing this: UnixSocketChannel.open(String) or similar seems more correct to me. You need to do this twice, for SOCK_STREAM and SOCK_DGRAM. If you go the route of using SocketChannel.open(SocketAddress), for example, now you've got instanceof checks for each socket type. Does this not seem like a so-called "code smell" to you? I've written an OO-ish socket abstraction, and I used struct sockaddr_storage as the glue between socket addresses and sockets (technically, I didn't even have to make the socket address class abstract, but I think I still did). There are some safety issues with this approach, though, and maybe OpenJDK needs to support systems without struct sockaddr_storage. I still maintain that it's the wrong solution - SocketAddress is a completely empty abstract class. Empty classes (like marker interfaces) add no value that cannot be gained in other, better ways. The only reason it exists is because C has sockaddr, so it seems like a reasonable thing to do. However, if one were to look at sockets afresh, looking at the similarities and differences between IP-based socket types and UNIX socket types, and designing the classes based on those ideals, I think the answer would be vastly different. Though this ideal is obviously not practical in many cases (especially in the case of the JDK), people should still think in this way, and then ask themselves, "How can I make what we have today be the most like this ideal?", rather than carry on a bad design just because that's how it has always been. - DML
Virtual Host support on the embedded HTTP server
I've crafted a simple patch which extends the API of the embedded HTTP
server to support virtual hosts. The patch is designed to add the new
functionality without breaking existing implementations which do not
support virtual hosts, or code which uses the HttpServer API today. It
does not include an implementation; however, the default implementation
should be easy to extend, from a brief look over the code.
The patch is attached. Please let me know what you think.
- DML
diff -r dde3fe2e8164 src/share/classes/com/sun/net/httpserver/HostMatcher.java
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/share/classes/com/sun/net/httpserver/HostMatcher.java Fri Dec 04 14:10:23 2009 -0600
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation. Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package com.sun.net.httpserver;
+
+/**
+ * A matcher which determines whether some incoming request matches a virtual
+ * host registration. See {...@link HttpServer#createVirtualHost(HostMatcher)} for
+ * more information about virtual host registration.
+ *
+ * @since 1.7
+ */
+public interface HostMatcher {
+/**
+ * Determine whether a HTTP request matches a virtual host registration.
+ *
+ * @param exchange the request exchange
+ * @return {...@code true} if the request matches, {...@code false} otherwise
+ */
+boolean matches(HttpExchange exchange);
+}
diff -r dde3fe2e8164 src/share/classes/com/sun/net/httpserver/HttpHost.java
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/share/classes/com/sun/net/httpserver/HttpHost.java Fri Dec 04 14:10:23 2009 -0600
@@ -0,0 +1,102 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation. Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package com.sun.net.httpserver;
+
+/**
+ * This class implements a simple HTTP host. A HttpHost may be "real" or "virtual".
+ * A "real" host is one which is bound to an IP address and extends the {...@link HttpServer}
+ * subclass. A "virtual" host allows for more than one set of registered contexts
+ * per physical server, differentiated by host name, IP address, or other criteria.
+ *
+ * One or more {...@link HttpHandler} objects must be associated with a host
+ * in order to process requests. Each such HttpHandler is registered
+ * with a root URI path which represents the
+ * location of the application or service on this server. The mapping of a handler
+ * to a {...@code HttpHost} is essentially equivalent to the mapping of a handler to a
+ * {...@link HttpServer}.
+ *
+ * @since 1.7
+ */
+public abstract class HttpHost {
+/**
+ * Creates a {...@code HttpContext}. A {...@code HttpContext} represents a mapping from a
+ * URI path to a exchange handler on this {
Re: Virtual Host support on the embedded HTTP server
If you want to. I also have another variation where there's a HttpVirtualHost subclass of HttpHost, which includes a "close()" method which removes the virtual host. That might make things a little more clear. Just specifying the host name is OK for some cases, but not for cases where you want to respond to "*.foo.com" with one "host", and "*.bar.com" with another, for example (which I think may be common even in simple installations - think pastebins, etc.). Also it doesn't help with IP-based virtual hosts, with which you'd have to run multiple instances, including one bound to 0.0.0.0 to catch the "default" case. Either way I don't see it affecting HttpsServer in any way, since virtual hosts have long been known not to work with HTTPS. I suppose the exception would be supporting IP-based virtual hosts. Well, either way I'd be happy taking your simple host-based idea and expanding it to support some kind of patterns - that would meet my use cases. - DML On 12/14/2009 07:28 AM, Christopher Hegarty - Sun Microsystems Ireland wrote: Hi David, I looked at the proposal and it looks pretty good, I just have a few concerns. HttpHost can be a virtual or real host, and HttpServer is an instance of a HTTP server running a virtual host. I think this concept is used in webservers like apache and Sun webserver. I always found it a little confusing, and I'm a little concerned that it will just confuse users of this simple http server API. Considering I wouldn't expect may users to use this advanced feature. I wonder if we could rework a simpler approach, maybe just simple name based virtual server? Possibly: HttpContext createContext(String host, String path, HttpHandler handler) Also, we need to think of the implications on HttpsServer. Michael (cc'ed) is the author of this API. Maybe he has an opinion. -Chris. On 07/12/2009 11:23, Christopher Hegarty - Sun Microsystems Ireland wrote: This is certainly interesting. Let me take a look and I'll get back to you later. -Chris. On 04/12/2009 20:17, David M. Lloyd wrote: I've crafted a simple patch which extends the API of the embedded HTTP server to support virtual hosts. The patch is designed to add the new functionality without breaking existing implementations which do not support virtual hosts, or code which uses the HttpServer API today. It does not include an implementation; however, the default implementation should be easy to extend, from a brief look over the code. The patch is attached. Please let me know what you think. - DML
Re: Virtual Host support on the embedded HTTP server
Responses inline.
On 12/14/2009 12:20 PM, Michael McMahon wrote:
Hi David,
Apologies for missing this when it was suggested originally.
Is there a particular use case you have in mind that requires the
generality provided by the HostMatcher interface? (as opposed to the
simpler name based approach as Chris said)
It's the simplest possible way I could think of to solve the problem,
that's all.
Presumably, with HostMatcher,
you would have to specify some way of deciding what to do if multiple
hosts try to claim the same request etc. Also, there would be a concern
whether it would scale performance wise.
First one wins. Evaluate them in order of registration. Performance-wise,
unless you have thousands of virtual hosts I wouldn't expect a measurable
impact.
The alternative is to select something O(1)-ish but this can drastically
limit what is possible. Though like I said, for my purposes if you would
allow for host name ("foo.bar.com") and a simple pattern mechanism
("*.bar.com" but not, say, "foo.*.com"), that'd be OK and it would still
let you have an O(1)-ish implementation (e.g. split by ".", evalulate
segments right-to-left, depth first, exact match first, wildcard match
second so longest match wins, not too unlike how contexts are matched I guess).
Unfortunately, the fact that HttpsServer is a sub-class of HttpServer
means we'd have to deal with the non-support of virtual hosts in Https,
at runtime, rather than at compile time. But that is likely to be the
case, whatever way this is done.
Well, you can (and should) still support them. They just have to meet the
requirements of the certificate presented (e.g. you can support
"foo.bar.com" and "baz.bar.com" if the cert is for "*.bar.com"). You don't
want to disable support for it in this case because they're still useful;
you just have to be aware of the rules. And who knows, maybe a future TLS
extension will make it generally viable, so you wouldn't want to rule it
out for this reason as well.
- DML
- Michael.
Christopher Hegarty - Sun Microsystems Ireland wrote:
Hi David,
I looked at the proposal and it looks pretty good, I just have a few
concerns.
HttpHost can be a virtual or real host, and HttpServer is an instance
of a HTTP server running a virtual host. I think this concept is used
in webservers like apache and Sun webserver. I always found it a
little confusing, and I'm a little concerned that it will just confuse
users of this simple http server API. Considering I wouldn't expect
may users to use this advanced feature.
I wonder if we could rework a simpler approach, maybe just simple name
based virtual server? Possibly: HttpContext createContext(String
host, String path, HttpHandler handler)
Also, we need to think of the implications on HttpsServer.
Michael (cc'ed) is the author of this API. Maybe he has an opinion.
-Chris.
On 07/12/2009 11:23, Christopher Hegarty - Sun Microsystems Ireland
wrote:
This is certainly interesting. Let me take a look and I'll get back
to you later.
-Chris.
On 04/12/2009 20:17, David M. Lloyd wrote:
I've crafted a simple patch which extends the API of the embedded
HTTP server to support virtual hosts. The patch is designed to
add the new functionality without breaking existing
implementations which do not support virtual hosts, or code which
uses the HttpServer API today. It does not include an
implementation; however, the default implementation should be easy
to extend, from a brief look over the code.
The patch is attached. Please let me know what you think.
- DML
Re: Virtual Host support on the embedded HTTP server
On 12/14/2009 03:58 PM, Michael McMahon wrote:
The alternative is to select something O(1)-ish but this can
drastically limit what is possible. Though like I said, for my
purposes if you would allow for host name ("foo.bar.com") and a simple
pattern mechanism ("*.bar.com" but not, say, "foo.*.com"), that'd be
OK and it would still let you have an O(1)-ish implementation (e.g.
split by ".", evalulate segments right-to-left, depth first, exact
match first, wildcard match second so longest match wins, not too
unlike how contexts are matched I guess).
I think this might be simpler.
OK, so how about this patch (attached, again just covers the API)?
- DML
diff -r dde3fe2e8164 src/share/classes/com/sun/net/httpserver/HttpHost.java
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/share/classes/com/sun/net/httpserver/HttpHost.java Mon Dec 14 16:22:37 2009 -0600
@@ -0,0 +1,103 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation. Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package com.sun.net.httpserver;
+
+/**
+ * This class implements a simple HTTP host. A HttpHost may be "real" or "virtual".
+ * A "real" host is one which is bound to an IP address and extends the {...@link HttpServer}
+ * subclass. A "virtual" host allows for more than one set of registered contexts
+ * per physical server, differentiated by host name, IP address, or other criteria.
+ *
+ * One or more {...@link HttpHandler} objects must be associated with a host
+ * in order to process requests. Each such HttpHandler is registered
+ * with a root URI path which represents the
+ * location of the application or service on this server. The mapping of a handler
+ * to a {...@code HttpHost} is essentially equivalent to the mapping of a handler to a
+ * {...@link HttpServer}.
+ *
+ * @since 1.7
+ */
+public abstract class HttpHost {
+/**
+ * Creates a {...@code HttpContext}. A {...@code HttpContext} represents a mapping from a
+ * URI path to a exchange handler on this {...@code HttpHost}. Once created, all requests
+ * received by the server for the path will be handled by calling
+ * the given handler object. The context is identified by the path, and
+ * can later be removed from the server using this with the {...@link #removeContext(String)} method.
+ *
+ * The path specifies the root URI path for this context. The first character of path must be
+ * {...@code '/'}.
+ * The class overview describes how incoming request URIs are mapped
+ * to HttpContext instances.
+ * @param path the root URI path to associate the context with
+ * @param handler the handler to invoke for incoming requests.
+ * @throws IllegalArgumentException if path is invalid, or if a context
+ * already exists for this path
+ * @throws NullPointerException if either path, or handler are null
+ */
+public abstract HttpContext createContext (String path, HttpHandler handler) ;
+
+/**
+ * Creates a {...@code HttpContext} without initially specifying a handler. The handler must later be specified using
+ * {...@link com.sun.net.httpserver.HttpContext#setHandler(com.sun.net.httpserver.HttpHandler)}. A {...@code HttpContext} represents a mapping from a
+ * URI path to an exchange handler on this {...@code HttpHost}. Once created, and when
+ * the handler has been set, all requests
+ * received by the server for the path will be handled by calling
+ * the handler object. The context is identified by the path, and
+ * can later be removed from the server using this with the {...@link #removeContext(String)} method.
+ *
+ * The path specifies the root URI path for this context. The first character of path must be
+ * {...@code '/'}.
+ * The class overview describes how incoming request URIs are mapped
+ * to HttpContext ins
Re: Http client API
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. So, all comments are welcome. Why not javax.net.httpclient? Having it be backportable to earlier JDKs would definitely help adoption IMO. -- - DML
Re: JEP 183: HTTP Cross-Origin Resource Sharing
On 04/11/2013 04:23 PM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/183 I have a few comments/random thoughts about this. It says: Security: Will need to be reviewed carefully since this feature does relax the network security model in two ways: No explicit network permission will be required for certain (simple) cross-origin HTTP requests, as defined by CORS. Permissions for other (non simple) requests will be delegated to the server hosting the target resource. I think this makes a lot of assumptions about the running code and its security environment (in particular it seems to target applets and JWS). Generally speaking, I think that the model of relaxing client security permissions based on a server resource is quite dangerous, in particular outside of an applet/JWS environment. I think a different model should be looked at that does not involve (effectively) granting HTTP connection privileges based on the server (at least, not always), but instead requires that the permissions already be granted; it would be more secure to use a separate client context which tracks what resources the server has granted access to, while still enforcing the full set of client permissions at all times. In this case it is the server that should be mistrusted, not the client, since the server is the party which is potentially granting permissions. If you grant an HTTP access permission to a server, you are implicitly giving that server the ability to grant the running code any other HTTP access permission they want. One thought is that applets/JWS could adopt the Java EE 7 permissions.xml model. This would be a convenient mechanism to give an application access to more than its original permission set, and it would still be possible to authorize the additional permissions with the user before the program is run. Thanks for listening. -- - DML
Re: possible NIO selector leak in 7u25
On 7/4/13 4:42 AM, Alan Bateman wrote: On 04/07/2013 09:36, Bernd Eckenfels wrote: Hello, we see a possible handle/selector leak very similiar to this bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118373 We see on linux unix domain sockets and on windows /dev/afd handles which are not backed up by any socket/selector/handle/channel in the heapdump. This is a applicxation using NIO (via JBoss XNIO). We would like to nail down the source of it and therefore it would be good if we have the actual code from the old bug above "e.java" to see if this helps us to reproduce the problem. Can any Oracle developer with access to it sent it? (and cvonfirm the bug is fixed) In our case we see >500 of those internal sockets, but the related tcp sockets (and java objects) are gone. Bernd Do you know if JBoss XNIO uses socket adapters to do timed reads? These were implemented as temporary Selectors and cached on a per thread basis. We've replaced this in jdk8 but for jdk7 and older then it is possible to have scenarios where there are a lot of threads or short-lived threads and the temporarily Selectors hang around until they are GC'ed. If you are using lsof or equivalent then it would be visible as an apparently build up of Unix domain sockets. You mention that the heap dump doesn't appear to have references and that make sense if the heap dump is generated from only the live objects (would be interesting to know if the Unix domain sockets are closed as as result of a heap dump that does a full GC first). There isn't an "e.java" attached to the bug. This bug is actually a "shadow bug" for something that came via another support/customer system so it has been filtered. When Rob fixed 7118373 then he wasn't able to come up with a reliable test case that demonstrated the issue in a reasonable amount of time. So are you able to duplicate the issue in your environment? I'm just wondering if you could try a preview build of 8 or event 7u40 to double check that the issue still duplicates. XNIO uses Selectors (usually PollSelectorImpls) which are cached per thread in order to mix blocking and non-blocking I/O. If you are starting many short-lived threads and doing blocking operations on XNIO channels then this might explain what is happening. The answer is basically "don't do that". -- - DML
Re: possible NIO selector leak in 7u25
On 7/4/13 1:53 PM, Alan Bateman wrote: On 04/07/2013 19:43, David M. Lloyd wrote: XNIO uses Selectors (usually PollSelectorImpls) which are cached per thread in order to mix blocking and non-blocking I/O. If you are starting many short-lived threads and doing blocking operations on XNIO channels then this might explain what is happening. The answer is basically "don't do that". When you say "usually PollSelectorImpls" then it normally run with it configured to use the poll based Selector? Yeah it will prefer PollSelectorImpl for temporary selectors, but will ultimately fall back to whatever the default provider gives. BTW: Sean Coffey mailed me off-list so say that he tried the original support/customer test case that lead to 7118373 and confirms that it doesn't duplicate with 7u25. Good to know, thanks. -- - DML
