RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Julia Boes 
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.

-

Commit messages:
 - fix whitespace
 - Move changes from sandbox to mainline

Changes: https://git.openjdk.java.net/jdk/pull/5505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5505&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245095
  Stats: 6891 lines in 42 files changed: 6856 ins; 15 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel [v2]

2021-09-14 Thread Masanori Yano 
On Mon, 13 Sep 2021 13:18:10 GMT, Daniel Fuchs  wrote:

>> Masanori Yano has updated the pull request with a new target base due to a 
>> merge or a rebase. The incremental webrev excludes the unrelated changes 
>> brought in by the merge/rebase. The pull request contains three additional 
>> commits since the last revision:
>> 
>>  - 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel
>>  - Merge branch 'master' of https://github.com/masyano/jdk into 8238274
>>  - 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel
>
> test/jdk/com/sun/nio/sctp/SctpChannel/CloseDescriptors.java line 29:
> 
>> 27:  * @summary Potential leak file descriptor for SCTP
>> 28:  * @requires (os.family == "linux")
>> 29:  * @run main CloseDescriptors
> 
> The test SctpMultiChannel/CloseDescriptors seems to work - at least it 
> doesn't fail all the time - but it's using `@run main/othervm`. I believe you 
> should make this test run in /othervm mode for more stability. I will test 
> again with your later change and /othervm mode.

I pushed a fix to run the test in othervm mode. Please test again.

-

PR: https://git.openjdk.java.net/jdk/pull/5274

Re: RFR: 8238274: (sctp) JDK-7118373 is not fixed for SctpChannel [v3]

2021-09-14 Thread Masanori Yano 
> Please review this change to the Unix implementations of 
> sun.nio.ch.sctp.Sctp*ChannelImpl#implCloseSelectableChannel() 
> to be same as SocketChannelImpl at JDK-7118373. (The preClose is missing a 
> check for the ST_KILLED state.)

Masanori Yano has updated the pull request incrementally with one additional 
commit since the last revision:

  8238274: (sctp) JDK-7118373 is not fixed for SctpChannel

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5274/files
  - new: https://git.openjdk.java.net/jdk/pull/5274/files/cd67ff8f..c3bfdfc4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5274&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5274&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5274/head:pull/5274

PR: https://git.openjdk.java.net/jdk/pull/5274

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Magnus Ihse Bursie 
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes  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.

Build changes look good.

-

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Andrey Turbanov 
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes  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.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 106:

> 104: var h = headers.entrySet().stream()
> 105: .collect(Collectors.toUnmodifiableMap(
> 106: Entry::getKey, e -> new 
> LinkedList<>(e.getValue(;

I wonder, what the reason of  `LinkedList` usages here?
As I know ArrayList is faster in all real-world scenarios.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Daniel Fuchs 
On Tue, 14 Sep 2021 13:19:17 GMT, Andrey Turbanov 
 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.
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 106:
> 
>> 104: var h = headers.entrySet().stream()
>> 105: .collect(Collectors.toUnmodifiableMap(
>> 106: Entry::getKey, e -> new 
>> LinkedList<>(e.getValue(;
> 
> I wonder, what the reason of  `LinkedList` usages here?
> As I know ArrayList is faster in all real-world scenarios.

Hi Andrey, IIRC from when I reviewed this code the current implementation of 
`Headers` already uses `LinkedList` in other places - so this preserves the 
concrete list implementation class that `Headers` uses (see `Headers::add`). 
Not that it matters much - but if we wanted to replace `LinkedList` with 
`ArrayList`  I believe we should do it consistently in this class - and 
probably outside of the realm of this JEP.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Andrey Turbanov 
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes  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.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 288:

> 286: }
> 287: 
> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new 
> Headers());

IDEA warns here:
>Referencing subclass UnmodifiableHeaders from superclass Headers initializer 
>might lead to class loading deadlock
>Such references can cause JVM-level deadlocks in multithreaded environment, 
>when one thread tries to load the superclass and another thread tries to load 
>the subclass at the same time.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Jaikiran Pai 
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes  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.

src/java.base/windows/classes/sun/net/www/content-types.properties line 30:

> 28: application/octet-stream: \
> 29:   description=Generic Binary Stream;\
> 30:   file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz

Hello Julia,
Is this an intentional change, to remove the mapping of `.zip` to 
`application/octet-stream`? In a later part of this patch there's a commented 
out test `testCommonExtensions` which deals with these extension types and that 
has a link to 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
 which states that `.zip` should be mapped to `application/zip` instead of the 
current `application/octet-stream`, so I'm guessing this changed line is 
intentional.

On an unrelated note, the unix variant of this file 
`src/java.base/unix/classes/sun/net/www/content-types.properties` interestingly 
uses `.z` for `.zip`? Commit history on that file doesn't provide any hint on 
whether that is intentional either.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Result: New Networking Group Member: Patrick Concannon

2021-09-14 Thread Daniel Fuchs 

The vote for Patrick Concannon [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

--daniel

[1] https://mail.openjdk.java.net/pipermail/net-dev/2021-August/016440.html

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Jaikiran Pai 
On Tue, 14 Sep 2021 15:30:31 GMT, Jaikiran Pai  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.
>
> src/java.base/windows/classes/sun/net/www/content-types.properties line 30:
> 
>> 28: application/octet-stream: \
>> 29:  description=Generic Binary Stream;\
>> 30:  file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz
> 
> Hello Julia,
> Is this an intentional change, to remove the mapping of `.zip` to 
> `application/octet-stream`? In a later part of this patch there's a commented 
> out test `testCommonExtensions` which deals with these extension types and 
> that has a link to 
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
>  which states that `.zip` should be mapped to `application/zip` instead of 
> the current `application/octet-stream`, so I'm guessing this changed line is 
> intentional.
> 
> On an unrelated note, the unix variant of this file 
> `src/java.base/unix/classes/sun/net/www/content-types.properties` 
> interestingly uses `.z` for `.zip`? Commit history on that file doesn't 
> provide any hint on whether that is intentional either.

I think you can ignore my comment above. I went and checked the 
`content-types.properties` in their current state for both unix and windows and 
they already have a separate `application/zip` which is mapped to `.zip`. So I 
think this above change shouldn't impact anything.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Julia Boes 
On Tue, 14 Sep 2021 15:42:06 GMT, Jaikiran Pai  wrote:

>> src/java.base/windows/classes/sun/net/www/content-types.properties line 30:
>> 
>>> 28: application/octet-stream: \
>>> 29: description=Generic Binary Stream;\
>>> 30: file_extensions=.saveme,.dump,.hqx,.arc,.obj,.lib,.bin,.exe,.gz
>> 
>> Hello Julia,
>> Is this an intentional change, to remove the mapping of `.zip` to 
>> `application/octet-stream`? In a later part of this patch there's a 
>> commented out test `testCommonExtensions` which deals with these extension 
>> types and that has a link to 
>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types
>>  which states that `.zip` should be mapped to `application/zip` instead of 
>> the current `application/octet-stream`, so I'm guessing this changed line is 
>> intentional.
>> 
>> On an unrelated note, the unix variant of this file 
>> `src/java.base/unix/classes/sun/net/www/content-types.properties` 
>> interestingly uses `.z` for `.zip`? Commit history on that file doesn't 
>> provide any hint on whether that is intentional either.
>
> I think you can ignore my comment above. I went and checked the 
> `content-types.properties` in their current state for both unix and windows 
> and they already have a separate `application/zip` which is mapped to `.zip`. 
> So I think this above change shouldn't impact anything.

That's right, there was a duplicate entry for `.zip` in the Windows properties 
file only, which I removed. 

I'm not sure if `.z` in the Unix properties file is intentional, but I do have 
a PR in progress in the same area, which I will link here shortly.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Julia Boes 
On Tue, 14 Sep 2021 13:47:48 GMT, Andrey Turbanov 
 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.
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 288:
> 
>> 286: }
>> 287: 
>> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new 
>> Headers());
> 
> IDEA warns here:
>>Referencing subclass UnmodifiableHeaders from superclass Headers initializer 
>>might lead to class loading deadlock
>>Such references can cause JVM-level deadlocks in multithreaded environment, 
>>when one thread tries to load the superclass and another thread tries to load 
>>the subclass at the same time.

Interesting, thanks for noting. We can return a new instance instead on line 
307, the only place the constant is used.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Daniel Fuchs 
On Tue, 14 Sep 2021 16:07:21 GMT, Julia Boes  wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 
>> 288:
>> 
>>> 286: }
>>> 287: 
>>> 288: private static final Headers EMPTY = new UnmodifiableHeaders(new 
>>> Headers());
>> 
>> IDEA warns here:
>>>Referencing subclass UnmodifiableHeaders from superclass Headers initializer 
>>>might lead to class loading deadlock
>>>Such references can cause JVM-level deadlocks in multithreaded environment, 
>>>when one thread tries to load the superclass and another thread tries to 
>>>load the subclass at the same time.
>
> Interesting, thanks for noting. We can return a new instance instead on line 
> 307, the only place the constant is used.

Or you could possibly define the constant in UnmodifiableHeaders instead.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Jim Laskey 
On Tue, 14 Sep 2021 12:36:28 GMT, Jim Laskey  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.
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java 
> line 128:
> 
>> 126:  *  {@code headers} are the effective headers of the response. 
>> The
>> 127:  * response body bytes are a {@code UTF-8} encoded byte 
>> sequence of
>> 128:  * {@code body}. The response {@linkplain 
>> HttpExchange#sendResponseHeaders(int, long) is sent}
> 
> Not sure what the javadoc looks like here, but it looks like the link is "is 
> sent". Curious.

Just a rewording, maybe.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Jim Laskey 
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes  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.

Very nice. LGTM.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 
128:

> 126:  *  {@code headers} are the effective headers of the response. The
> 127:  * response body bytes are a {@code UTF-8} encoded byte 
> sequence of
> 128:  * {@code body}. The response {@linkplain 
> HttpExchange#sendResponseHeaders(int, long) is sent}

Not sure what the javadoc looks like here, but it looks like the link is "is 
sent". Curious.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpsServer.java line 
152:

> 150: return server;
> 151: }
> 152: 

Too bad we couldn't simplify the setting up a basic certificate for https.

-

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Daniel Fuchs 
On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes  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.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java line 
129:

> 127:  * response body bytes are a {@code UTF-8} encoded byte 
> sequence of
> 128:  * {@code body}. The response {@linkplain 
> HttpExchange#sendResponseHeaders(int, long) is sent}
> 129:  * with the given {@code statusCode} and the body bytes' length. The 
> body

That might give the impression that chunked encoding will be used if the body 
length is 0. I wonder if it should say instead:


with the given {@code statusCode} and a {@code Content-Length} field set to the 
body bytes' length.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Daniel Fuchs 
On Tue, 14 Sep 2021 12:38:19 GMT, Jim Laskey  wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java 
>> line 128:
>> 
>>> 126:  *  {@code headers} are the effective headers of the response. 
>>> The
>>> 127:  * response body bytes are a {@code UTF-8} encoded byte 
>>> sequence of
>>> 128:  * {@code body}. The response {@linkplain 
>>> HttpExchange#sendResponseHeaders(int, long) is sent}
>> 
>> Not sure what the javadoc looks like here, but it looks like the link is "is 
>> sent". Curious.
>
> Just a rewording, maybe.

Hmm... Maye that should be "The response headers *are sent*". The non-obvious 
technical details is that the response headers are sent before the body - as 
soon as you call  `sendResponseHeaders`. The link is here to provide a better 
understanding of the workings of the new Handler. The headers are sent by 
calling `sendResponseHeaders` on the HttpExchange.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Daniel Fuchs 
On Tue, 14 Sep 2021 16:47:45 GMT, Daniel Fuchs  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.
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpHandlers.java 
> line 129:
> 
>> 127:  * response body bytes are a {@code UTF-8} encoded byte 
>> sequence of
>> 128:  * {@code body}. The response {@linkplain 
>> HttpExchange#sendResponseHeaders(int, long) is sent}
>> 129:  * with the given {@code statusCode} and the body bytes' length. 
>> The body
> 
> That might give the impression that chunked encoding will be used if the body 
> length is 0. I wonder if it should say instead:
> 
> 
> with the given {@code statusCode} and a {@code Content-Length} field set to 
> the body bytes' length.

Or maybe - which would be more accurate:


with the given {@code statusCode} and the body bytes' length (or {@code -1} if 
the body is empty).

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value [v2]

2021-09-14 Thread Jonathan Dowland 
On Fri, 10 Sep 2021 14:17:32 GMT, Daniel Fuchs  wrote:

>> Jonathan Dowland has updated the pull request with a new target base due to 
>> a merge or a rebase. The incremental webrev excludes the unrelated changes 
>> brought in by the merge/rebase. The pull request contains one additional 
>> commit since the last revision:
>> 
>>   8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP 
>> value
>
> Hi Jonathan, this should be ready to integrate so please enter /integrate in 
> a new comment and then it can be sponsored.

@dfuch thanks for the prompt and sorry for the delay!

-

PR: https://git.openjdk.java.net/jdk/pull/4806

Integrated: 8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value

2021-09-14 Thread Jonathan Dowland 
On Fri, 16 Jul 2021 09:16:23 GMT, Jonathan Dowland  wrote:

> The tests `test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java` uses 
> the IP address "1.1.1.1" as a value. I think at the time the address was 
> picked, the assumption was the address was not valid / not routable. Since 
> April 2018 the address is part of CloudFlare's "Free" DNS product: 
> . (this test was originally written in 
> 2016, before the service was launched)
> 
> I've verified using local packet captures that running the test does result 
> in IP traffic being sent to 1.1.1.1. (Several other tests in JDK use 1.1.1.1 
> as a placeholder IP. I've checked them all and none of the others connect out 
> to the IP like this one)
>  
> This PR substitutes that IP address value (and two others) for ones from a 
> reserved IP range (240.0.0.0/4 according to RFC 6761) which will not result 
> in runners of the test suit inadvertently sending IP packets to the 
> CloudFlare service. 
> 
> This could be invalidated again if that address range is allocated at some 
> point in the future. A more future-proof fix would be to bind to random ports 
> on localhost for each dummy proxy (as done for the target HTTP server in the 
> test already). I can do that if preferred.
> 
> 

This pull request has now been integrated.

Changeset: 394ebc86
Author:Jonathan Dowland 
Committer: Daniel Fuchs 
URL:   
https://git.openjdk.java.net/jdk/commit/394ebc8642366bc16aedde0d7f09fe4214f14cdd
Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8270553: Tests should not use (real, in-use, routable) 1.1.1.1 as dummy IP value

Reviewed-by: shade, dfuchs

-

PR: https://git.openjdk.java.net/jdk/pull/4806

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Florent Guillaume 
On Tue, 14 Sep 2021 15:56:53 GMT, Julia Boes  wrote:

>> I think you can ignore my comment above. I went and checked the 
>> `content-types.properties` in their current state for both unix and windows 
>> and they already have a separate `application/zip` which is mapped to 
>> `.zip`. So I think this above change shouldn't impact anything.
>
> That's right, there was a duplicate entry for `.zip` in the Windows 
> properties file only, which I removed. 
> 
> I'm not sure if `.z` in the Unix properties file is intentional, but I do 
> have a PR in progress in the same area, which I will link here shortly.

FWIW `.z` is the extension of the old Unix `compress` program.

-

PR: https://git.openjdk.java.net/jdk/pull/5505

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server

2021-09-14 Thread Jaikiran Pai 
On Wed, 15 Sep 2021 01:54:40 GMT, Florent Guillaume 
 wrote:

> FWIW `.z` is the extension of the old Unix `compress` program.

Thank you Florent, I wasn't aware of that.

-

PR: https://git.openjdk.java.net/jdk/pull/5505