RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
jboes at openjdk.java.net
Fri Sep 17 14:35:43 UTC 2021
On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes <jboes at openjdk.org> wrote:
>> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`.
>> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK.
>> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging.
>> Additionally, a small API is introduced for programmatic creation and customization.
>> Testing: tier1-3.
> Julia Boes has updated the pull request incrementally with one additional commit since the last revision:
> correct path handling
> _Mailing list message from [Jaikiran Pai](mailto:jai.forums2013 at gmail.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
> Hello Bernd,
> On 17/09/21 3:37 am, Bernd Eckenfels wrote:
> > I also wonder if it makes sense to either only serve files with public permissions, or at least Filter some critical files like .ssh/* and *.jks.
> FWIW - From what I can see in the proposed implementation as well as the
> JEP text, hidden files and symbolic links aren't served. So it should
> prevent listing/serving .ssh/ directory.
File system access is checked for the root directory and the requested resource (summarized in the CSR ). You're right that hidden files, symbolic links, and not-readable files are not served. Looking at the example of `.ssh/*`, I realize we missed the case where a component of the request path is hidden (or not readable), rather than the requested resource itself. For example, if `/` is the server's root directory, a request of `http://host:port/.ssl/config` would be successful because config is not hidden. A request of `http://host:port/.ssl` would get a 404. I'll update this to apply the isHidden and isReadable checks to the requested resource *as well as* all components of its path.
No further group/owner/other permissions are checked - that's a can of worms we didn't want to get in to, given that this server is really not appropriate for serving file hierarchies that contain sensitive information. Again, it's a simple tool for development and testing purposes only.
More information about the core-libs-dev