Hi,
I’d like to call attention to a project I’ve released
http://github.com/robaho/httpserver
It is essentially the JDK httpserver but modified to remove all async and also
adds connection upgrade support to enable web sockets.
Would the net-dev team be interested in a PR covering these ch
See github.com/robaho/httpserver for a more capable fork of the JDK code.
Would love to create a PR to move the core changes back into the JDK but the
net-dev folks don’t seem to be interested
> On Jan 22, 2024, at 1:18 AM, Alan Bateman wrote:
> On 21/01/2024 20:18, Ethan McCue wrote:
>>
jdk.
Anyway, thanks for the update - I’ll need to go back and see why I missed it -
I thought I had just been ignored :)
> On Jan 22, 2024, at 3:08 AM, Alan Bateman wrote:
>
> On 22/01/2024 08:43, Robert Engels wrote:
>> See github.com/robaho/httpserver for a more capable
When doing some testing on github.com/robaho/httpserver - which is a fork of the jdk http server, I discovered a significant performance issue.When an http connection is in ‘keep-alive’ - the default for http 1.1 - the headers are “flushed” here https://github.com/openjdk/jdk21/blob/890adb6410dab
When doing some testing on github.com/robaho/httpserver - which is a fork of the jdk http server, I discovered a significant performance issue.When an http connection is in ‘keep-alive’ - the default for http 1.1 - the headers are “flushed” here https://github.com/openjdk/jdk21/blob/890adb6410dab4
for bringing this up! We are aware of the issue, it's tracked under
> https://bugs.openjdk.org/browse/JDK-6968351.
>
> If you have an idea for a proper fix that doesn't add too much complexity,
> please open a PR, and we'll be happy to help.
> Cheers,
> Daniel
&
I filled out the OCA. It may be in a pending review status?
> On Apr 7, 2024, at 1:38 AM, Alan Bateman wrote:
>
>
>
>> On 07/04/2024 00:37, robert engels wrote:
>> Hi Daniel,
>>
>> Here is a PR which fixes it.
>
> I don't think anyone will b
I proceeding now. I guess when/if the OCA is approved someone will check it out.
> On Apr 7, 2024, at 5:45 AM, Robert Engels wrote:
>
> I filled out the OCA. It may be in a pending review status?
>
>
>> On Apr 7, 2024, at 1:38 AM, Alan Bateman wrote:
>>
>&
Sorry, “it’s” proceeding now. Says could be 1-2 weeks but usually 1-2 business
days.
> On Apr 7, 2024, at 9:40 AM, robert engels wrote:
>
> I proceeding now. I guess when/if the OCA is approved someone will check it
> out.
>
>> On Apr 7, 2024, at 5:45 AM, Robert En
That
>> test was recently modified to add -Dsun.net.httpserver.nodelay=true
>> [1], because it took forever to complete on LInux machines. On other
>> OSes the problem is not visible in existing tests.
>> Cheers,
>> Daniel
>>
>> [1] https://github.com/openjdk/jdk
I’ll update my PR to remove the nodelay setting from those tests. I am going to
change the PR to use UrlConnection rather than HttpClient as well.
> On Apr 8, 2024, at 7:10 AM, Robert Engels wrote:
>
> I added a new test specifically to address this issue. Ran fine on osx
> wit
;
> best regards,
>
> -- daniel
>
>> On 08/04/2024 14:23, Robert Engels wrote:
>> I’ll update my PR to remove the nodelay setting from those tests. I am going
>> to change the PR to use UrlConnection rather than HttpClient as well.
>
>
And thanks for the note about HttpClient - ill leave that as is then.
> On Apr 8, 2024, at 9:06 AM, Robert Engels wrote:
>
> It’s fairly isolated but I haven’t checked to see how the JDK differs in
> jdk8 - but I’m guessing not very much so it should be a trivial port.
>
&g
fix bug JDK-B6968351 by avoiding flush after response headers
-
Commit messages:
- remove extraneous whitespace change
- fix for small messages with tcp_nodelay off
Changes: https://git.openjdk.org/jdk/pull/18667/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18667&range=
The OCA tag has been removed. So it’s ok to review now.
> On Apr 8, 2024, at 9:10 AM, Robert Engels wrote:
>
> And thanks for the note about HttpClient - ill leave that as is then.
>
>> On Apr 8, 2024, at 9:06 AM, Robert Engels wrote:
>>
>> It’s fairly iso
On Fri, 19 Apr 2024 12:37:18 GMT, Daniel Jeliński wrote:
>> Forget I asked this. @djelinski pointed out this is necessary to avoid
>> having to flush at line 281. But I see that at line 686 you replaced rawout
>> with a BufferedOutputStream - so do we still need the temporary
>> ByteArrayOutpu
On Fri, 19 Apr 2024 09:48:49 GMT, Daniel Jeliński wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 45:
>
>> 43: import java.util.logging.*;
>> 44:
>> 45: public class B6968351 {
>
> You could use a more revealin
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
update based on PR review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
On Fri, 19 Apr 2024 09:08:54 GMT, Daniel Fuchs wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update based on PR review
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java l
On Fri, 19 Apr 2024 09:54:48 GMT, Daniel Jeliński wrote:
> This is not as complex as I expected it to be. Which is a good thing!
>
> Some tests are failing with this change. See:
>
> ```
> test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
> test/jdk/java/net/Authenticator/B4769350.java
> `
On Fri, 19 Apr 2024 15:42:15 GMT, Daniel Jeliński wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update based on PR review
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java
On Fri, 19 Apr 2024 15:26:19 GMT, Daniel Fuchs wrote:
>> This was done to match the other tests with similar naming in this
>> directory, but I am not against changing it.
>
> I agree with Daniel here - with new tests we try to use a more descriptive
> name. I hate to see JBS issues titled `foo
On Fri, 19 Apr 2024 16:17:35 GMT, Michael McMahon wrote:
> > This is not as complex as I expected it to be. Which is a good thing!
> > Some tests are failing with this change. See:
> > ```
> > test/jdk/sun/net/www/http/KeepAliveCache/B8293562.java
> > test/jdk/java/net/Authenticator/B4769350.java
On Fri, 19 Apr 2024 16:03:42 GMT, Daniel Jeliński wrote:
> The problem with closing a chunked stream is that it flushes both before and
> after the final chunk. I assume it may also cause delays.
>
> The only case when you don't need to close the exchange or the output stream
> is when your re
On Fri, 19 Apr 2024 16:39:37 GMT, robert engels wrote:
> B4769350
I don't understand this. If the handler "leaks it", isn't that a bug? If
sending a chunked response I think you have to close the output stream or end
the exchange otherwise it is a bug in the handler c
On Fri, 19 Apr 2024 17:27:16 GMT, Daniel Jeliński wrote:
> Yes it is a bug. But even with the bug the code used to work, and now it
> doesn't. Users might have similar buggy code that will stop working when they
> get this fix. We need to post a release note so that they know what to expect.
A
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with two additional
commits since the last revision:
- automatically close a fixed response. this is benign as a further close is
ignore, and a further write continues
On Fri, 19 Apr 2024 17:10:43 GMT, robert engels wrote:
> > B4769350
>
> I don't understand this. If the handler "leaks it", isn't that a bug? If
> sending a chunked response I think you have to close the output stream or end
> the exchange otherwise it i
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
fix jtreg params
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
On Fri, 19 Apr 2024 17:24:33 GMT, Daniel Jeliński wrote:
>>> The problem with closing a chunked stream is that it flushes both before
>>> and after the final chunk. I assume it may also cause delays.
>>>
>>> The only case when you don't need to close the exchange or the output
>>> stream is wh
On Fri, 19 Apr 2024 18:15:26 GMT, Daniel Jeliński wrote:
>>> The problem with closing a chunked stream is that it flushes both before
>>> and after the final chunk. I assume it may also cause delays.
>>>
>>> The only case when you don't need to close the exchange or the output
>>> stream is wh
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
ignore flush() on closed stream
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
-
On Fri, 19 Apr 2024 18:12:14 GMT, Daniel Jeliński wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jtreg params
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLeng
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
fix chunked response for small packets
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/fi
On Fri, 19 Apr 2024 18:17:56 GMT, robert engels wrote:
>> https://github.com/openjdk/jdk/blob/b704e91241b0f84d866f50a8f2c6af240087cb29/src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java#L140-L144
>
> I figured out what you are referring to. Let me look a
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with two additional
commits since the last revision:
- avoid sending multiple empty chunks
- test both fixed and chunked responses
-
Changes:
- all: ht
On Fri, 19 Apr 2024 18:44:52 GMT, Daniel Fuchs wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix chunked response for small packets
>
> src/jdk.httpserver/sh
On Fri, 19 Apr 2024 18:50:10 GMT, Daniel Fuchs wrote:
>> yes, let me fixed that.
>
> Shouldn't you look at whether count > 0 as is done in flush() ?
corrected. good catch.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1572783063
On Fri, 19 Apr 2024 18:40:20 GMT, robert engels wrote:
>> I figured out what you are referring to. Let me look at this, I am pretty
>> sure I can remove the first flush.
>
> I posted a fix which addresses this. I will modify the test case to test both
> methods of retu
On Fri, 19 Apr 2024 18:28:19 GMT, robert engels wrote:
>> src/jdk.httpserver/share/classes/sun/net/httpserver/FixedLengthOutputStream.java
>> line 68:
>>
>>> 66: remaining --;
>>> 67: if(remaining==0) {
>>> 68: clo
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
avoid sending multiple empty chunks
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/fi
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
avoid sending multiple empty chunks
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/fi
On Fri, 19 Apr 2024 19:15:19 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> avoid sending multiple empty chu
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
need to flush before close
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
On Fri, 19 Apr 2024 19:48:24 GMT, robert engels wrote:
> Hi all. Hold off on further review. My local OSX version is failing - but
> strangely the linux version is working. I believe the environment may be
> corrupted but I need to track down what is happening.
Everything is workin
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
rename testcase for clarity
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
-
On Fri, 19 Apr 2024 15:45:50 GMT, robert engels wrote:
>> I agree with Daniel here - with new tests we try to use a more descriptive
>> name. I hate to see JBS issues titled `foo/bar/BNN.java failed` - and
>> then I have no clue of what that test might be doing :-)
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
fix jtreg params
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
remove FixLengthOutputStream changes since not needed
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Sun, 21 Apr 2024 18:49:45 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove FixLengthOutputStream cha
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
flush after exchange returns
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
-
On Mon, 22 Apr 2024 12:16:14 GMT, Daniel Jeliński wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> flush after exchange returns
>
> src/jdk.httpserver/share/classes/sun/net/https
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
Revert "flush after exchange returns"
This reverts commit 30340e58be8ae08205400079b05
On Mon, 22 Apr 2024 12:16:14 GMT, Daniel Jeliński wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> flush after exchange returns
>
> src/jdk.httpserver/share/classes/sun/net/https
On Mon, 22 Apr 2024 12:45:01 GMT, Daniel Jeliński wrote:
>> I reverted the commit. I think my comment that the TcpNoDelayNotRequired
>> hangs the client connection if the stream is not closed - in the existing
>> JDK code - shows that the concern regarding "existing code" is not valid. I
>> th
On Mon, 22 Apr 2024 12:50:31 GMT, robert engels wrote:
>> We don't want to allow it; we want to fix the broken tests, and add a
>> release note so that the users know how to recognize that their code is
>> broken and know how to fix it.
>>
>> This should
On Mon, 22 Apr 2024 14:10:01 GMT, Daniel Fuchs wrote:
>>> We don't want to allow it; we want to fix the broken tests, and add a
>>> release note so that the users know how to recognize that their code is
>>> broken and know how to fix it.
>>>
>>> This should be fine in a new JDK version, where
On Mon, 22 Apr 2024 14:51:30 GMT, Daniel Fuchs wrote:
>> Prior to this change, If the handler does not close the body output stream
>> or exchange, then yes, the client will see those headers but if it tries to
>> send another request - which will reuse the same connection by default in
>> Htt
On Mon, 22 Apr 2024 15:39:30 GMT, Daniel Fuchs wrote:
>> I already removed that line - it is not necessary (but I also think it is
>> fine - there is no race/corruption possible, and it would restore the
>> previous behavior of always sending the headers).
>>
>> To your point though, I think I
On Mon, 22 Apr 2024 18:52:00 GMT, Daniel Jeliński wrote:
>> If I write a test case "test multiple requests without closing" - and add
>> that test case to earlier JDK versions, it will fail every time - with no
>> setting that would allow it to work.
>>
>> So trying to protect earlier bad code
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
remove timing check and rely on the test harness timeout
-
Changes:
- all: https://git.openjdk.org/
On Tue, 23 Apr 2024 08:29:41 GMT, Daniel Jeliński wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert "flush after exchange returns"
>>
>> This reverts c
On Tue, 23 Apr 2024 15:24:52 GMT, Michael McMahon wrote:
>> I’ll update the PR to fix the tests. I understand the need for backwards
>> compatibility- it’s one of the prime reasons Java is awesome - but in this
>> situation the tests are validating that 1+1=3 and I don’t think anyone wants
>>
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
fix broken test cases
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
On Tue, 23 Apr 2024 16:19:12 GMT, robert engels wrote:
>> If the client was based on HttpURLConnection in Java and if the code was
>> doing HTTP authentication then it's possible it could happen because
>> HTTPURLConnection closes the connection in between each phase of
On Tue, 23 Apr 2024 19:08:06 GMT, robert engels wrote:
>> If the handler sends headers(code,0) and doesn't close the stream, the
>> connection is dead. If what you are saying is that the old behavior was to
>> send the headers at this point, the client would s
On Wed, 24 Apr 2024 08:31:14 GMT, Michael McMahon wrote:
>> By the way, as an x-Googler I am familiar with Hyrum and have seen the link.
>>
>> Since the api allows for async handling - validating that an arbitrary
>> handler closes the stream doesn't seem possible other than by testing that
>
On Thu, 25 Apr 2024 12:11:42 GMT, Jaikiran Pai wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotR
On Thu, 25 Apr 2024 12:39:56 GMT, Jaikiran Pai wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix broken test cases
>
> test/jdk/java/net/Authenticator/B4769350.java line 35
On Thu, 25 Apr 2024 12:50:23 GMT, Jaikiran Pai wrote:
>> Isn’t consistency in the code base more important. I like the change but it
>> seems there should be a single PR that changes all of the test cases to this
>> format.
>
> We have been using these newer constructs whenever a new test gets
On Thu, 25 Apr 2024 12:58:36 GMT, robert engels wrote:
>> We have been using these newer constructs whenever a new test gets added,
>> but we don't update all tests in one go for such changes. If/when old tests
>> are updated for some bug fix relevant to that
On Thu, 25 Apr 2024 13:29:25 GMT, Michael McMahon wrote:
>> I think a better solution would be to add a constant to the api class -
>> rather than adding comments everywhere. E.g NO_CONTENT=-1 and
>> UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTENT=0
>
>> I think a better solu
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
update copyright date
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
clean and move test based on PR review
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/fi
On Thu, 25 Apr 2024 13:36:53 GMT, robert engels wrote:
>>> I think a better solution would be to add a constant to the api class -
>>> rather than adding comments everywhere. E.g NO_CONTENT=-1 and
>>> UNLIMITED_CONTENT=0 or INDETERMINENT_CONTENT=0, or CHUNKED_CONTEN
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
document chunk handing explicitly
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
-
On Thu, 25 Apr 2024 12:17:22 GMT, Jaikiran Pai wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotR
On Thu, 25 Apr 2024 12:28:25 GMT, Jaikiran Pai wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix broken test cases
>
> test/jdk/com/sun/net/httpserver/bugs/TcpNoDelayNotR
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
add https testing
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
Update full name
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
On Thu, 25 Apr 2024 14:40:36 GMT, robert engels wrote:
>> I’m on mobile now so I haven’t looked at the api - but I think adding
>> default methods like
>>
>> sendResponseHeadersNoContent(int code)
>>
>> and OutputStream sendResponseHead
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
use try with resource for HttpClient
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/fi
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with two additional
commits since the last revision:
- Update
src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java
Co-authored-by: Dan
On Thu, 25 Apr 2024 16:02:06 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use try with resource for HttpC
On Thu, 25 Apr 2024 15:49:23 GMT, Daniel Fuchs wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add https testing
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Https
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with two additional
commits since the last revision:
- Merge remote-tracking branch 'robaho/B6968351' into B6968351
- no need for tcp nodelay a
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with two additional
commits since the last revision:
- update copyright date
- update copyright date
-
Changes:
- all: https://git.openjdk.org/jdk/p
> fix bug JDK-B6968351 by avoiding flush after response headers
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
update copyright date
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
On Fri, 26 Apr 2024 08:23:32 GMT, Michael McMahon wrote:
>> I created a PR for the api changes https://github.com/openjdk/jdk/pull/18955
>
>> I created a PR for the api changes #18955
>
> I am working on a PR with some other API changes. I'd prefer to include this
> change in that one as well.
On Fri, 26 Apr 2024 09:01:49 GMT, Jaikiran Pai wrote:
>> done
>
> Thank you Robert for considering the review comments and updating several
> parts of this new test.
You're welcome. Happy to help.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18667#discussion_r1580995713
On Fri, 26 Apr 2024 13:24:08 GMT, Michael McMahon wrote:
> > > I created a PR for the related proposed api changes #18955
> >
> >
> > I don't think I have the ability to create issues, so I can't create one
> > for the api changes.
>
> I created a new Jira issue for this. It's at:
> https://
improve the HttpExchange api with documented constants and convenience methods
to avoid common bugs
-
Commit messages:
- improve HttpExchange response api
Changes: https://git.openjdk.org/jdk/pull/18955/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18955&range=00
Issue
> improve the HttpExchange api with documented constants and convenience
> methods to avoid common bugs
robert engels has updated the pull request incrementally with four additional
commits since the last revision:
- Update
src/jdk.httpserver/share/classes/com/sun/net/http
> improve the HttpExchange api with documented constants and convenience
> methods to avoid common bugs
robert engels has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/jdk.httpserver/share/classes/com/sun/net/http
On Fri, 26 Apr 2024 14:54:30 GMT, Michael McMahon wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.
On Tue, 30 Apr 2024 15:40:20 GMT, Daniel Fuchs wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.
On Tue, 30 Apr 2024 15:35:10 GMT, Daniel Fuchs wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>> line 246:
>>
>>> 244: * @see HttpExchange#sendResponseHeaders(int, long)
>>> 245: */
>>> 246: public final void sendResponseHeaders(int code,byte[]
On Tue, 30 Apr 2024 16:04:25 GMT, Daniel Fuchs wrote:
>> The purpose was that if you state you are sending a chunked response, you
>> must close the output stream. By returning it - the linter will catch that
>> it is closed, or used in a try-with-resources.
>
> I understand - but in this case
On Wed, 1 May 2024 11:21:59 GMT, Mark Sheppard wrote:
> sendResponseHeaderChunked The description implies that this method is sending
> a chunked response, but the method is not doing that. ...
I don't think it is implying that. The methods:
OutputStream sendResponseHeadersChunked(int code);
On Wed, 1 May 2024 13:06:02 GMT, Daniel Fuchs wrote:
> Maybe the lesser of the two evil would be to return `void`.
If you return void you prevent the linter from trapping the improper use of the
OutputStream. If you use these methods - or even the existing similar structure
- you must get and
1 - 100 of 149 matches
Mail list logo
