SO_REUSEADDR
Hi, the javadocs for SocketOptions.SO_REUSEADDR states that: "This is used only for MulticastSockets in java". However, the javadocs for ServerSocket.setReuseAddress(boolean) goes a great length explaining a behavior that applies to TCP sockets (referencing SocketOptions.SO_REUSEADDR). Similarly, the javadocs for SocketOptions.SO_REUSEPORT states: "This option enables and disables the ability to have multiple sockets listen to the same address and port." This seems to apply to listening sockets only, but then it says that it is valid for SocketImpl (not ServerSocketImpl). Can this be clarified? I did not look much further if there are other inconsistencies, but a more general review may be needed. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Re: SO_REUSEADDR
On 11/11/2020 10:14, Simone Bordet wrote: Hi, the javadocs for SocketOptions.SO_REUSEADDR states that: "This is used only for MulticastSockets in java". However, the javadocs for ServerSocket.setReuseAddress(boolean) goes a great length explaining a behavior that applies to TCP sockets (referencing SocketOptions.SO_REUSEADDR). Similarly, the javadocs for SocketOptions.SO_REUSEPORT states: "This option enables and disables the ability to have multiple sockets listen to the same address and port." This seems to apply to listening sockets only, but then it says that it is valid for SocketImpl (not ServerSocketImpl). Can this be clarified? java.net.StandardSocketOptions is the "user facing API" that has clear descriptions of the standard socket options. That's the place to read about SO_REUSEADDR and SO_REUSEPORT. java.net.SocketOptions is a legacy JDK 1.1 interface for the underlying socket implementations (SocketImpl, DatagramSocketImpl). It's really SPI rather than API and you shouldn't find any usages in any of the APIs. So yes, there is technical debt here and ideally there would be pass done over Socket and ServerSocket to change the links. It might also be useful to put text in the SocketOptions class description to redirect people to StandardSocketOptions. -Alan
RFR: 8255244: HttpClient: Response headers contain incorrectly encoded Unicode characters
The HTTP/1.1 Header Parser of the new HttpClient currently assumes that all headers (names and value) are US-ASCII and as a result mis-decode any byte whose value is > 127; For instance, 0x80 (128) gets decoded as a U+FF80 (65408) instead of being either rejected or decoded as U+0080. Historically, HTTP has allowed field content with text in the ISO-8859-1 charset. The ISO-8859-1 charset is also supported by `HttpURLConnection`. We could decide to reject responses whose headers contain non US-ASCII characters out of hand, but for compatibility reasons, it seems preferable to interpret and accept any byte > 127 in header values as an ISO-8859-1 (Latin 1) character. For backward compatibility, this change proposes to update the HTTP/1.1 Header Parser to support ISO-8859-1 encoding. The HTTP/1.1 Header Parser will now apply the same validation than is already applied by the HTTP/2 stack. - Commit messages: - 8255244: HttpClient: Response headers contain incorrectly encoded Unicode characters Changes: https://git.openjdk.java.net/jdk/pull/1169/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1169&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255244 Stats: 561 lines in 6 files changed: 535 ins; 0 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/1169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1169/head:pull/1169 PR: https://git.openjdk.java.net/jdk/pull/1169
