On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan wrote:
> Please review this change to terminally deprecate the following security
> related permission classes: `java.security.AllPermission`,
> `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`,
> `javax.security.auth.AuthPermissi
There is an rfc to disable the masking for TLS websocket connections
https://www.ietf.org/archive/id/draft-damjanovic-websockets-nomasking-00.html
I’m not sure how much time I would spend refactoring this.
> On Mar 14, 2025, at 10:17 AM, Mark Sheppard wrote:
>
> On Fri, 14 Mar 2025 10:11:29
he declared endianess.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: net-dev im Auftrag von Robert Engels
>
> Gesendet: Freitag, März 14, 2025 4:01 AM
> An: Mark Sheppard
> Cc: net-dev@openjdk.org
> Betreff: Re: RFR: 8351339: WebSocket::sendBinar
No. It is a simple bug. The payload is defined to be a byte stream. It should
never be manipulated. The implementation MUST send the bytes exactly as the api
caller provided.
But I think there is something else at play - the implementation should not be
reading the bytes at all - which is the
Congrats Jaikiran
> On Mar 5, 2025, at 9:18 AM, Daniel Fuchs wrote:
>
> Hi,
>
> The vote for Jaikiran Pai (jpai) [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.
>
> best
Sorry for the curtness. Thank you for replying. On mobile.
> On Jan 20, 2025, at 12:41 PM, Robert Engels wrote:
>
> HTTPS incurs considerable overhead. The reason for prior knowledge http2
> connections is to be able to get the multiplexing features of http2 without
> p
l I'm not sure there's a lot of appeal into supporting
> prior knowledge for clear HTTP/2 connections.
>
>
> best regards,
>
> -- daniel
>
>
>> On 11/01/2025 20:10, robert engels wrote:
>> Hi,
>> According to RFC 9113 which obsoletes 7540, the Http2 u
ddress this? Is there an outstanding bug I could work on?
>
> Thanks,
> Robert Engels
start.
The latter half of this addresses the “http2 with prior knowledge” portion of
the specification. The current behavior is not compliant with RFC 9113.
Are there plans to address this? Is there an outstanding bug I could work on?
Thanks,
Robert Engels
Jan 6, 2025, at 8:17 AM, robert engels wrote:
>
> And to clarify on what brought me to this, many servers implement http
> pipelining. Being able to detect that the request has more data after it (ie
> another request) allows the server to be far more efficient. Sending garbage
>
On Thu, 9 Jan 2025 13:06:55 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which clarifies the purpose
> of the HTTP server that's provided in the JDK's `jdk.httpserver` module? This
> should help avoid any confusion on the purpose of the server.
It is concerning
Pai wrote:
>
> Hello Robert,
>
> On 07/01/25 12:05 am, robert engels wrote:
> > ...
> >
> > 2. Another proposed change to Headers would be to add a protected
> > constructor that allowed you to pass in the Map implementation (or null),
> > allowing sp
On Thu, 9 Jan 2025 13:06:55 GMT, Jaikiran Pai wrote:
> Can I please get a review of this doc-only change which clarifies the purpose
> of the HTTP server that's provided in the JDK's `jdk.httpserver` module? This
> should help avoid any confusion on the purpose of the server.
This proposed cha
On Jan 8, 2025, at 2:04 AM, Alan Bateman wrote:
>
> On 07/01/2025 15:18, robert engels wrote:
>> Hi,
>>
>> I would like to revisit this. I have signed the OCA for another PR I worked
>> on - I believe it covers all of my contributions.
>>
>> The w
AM, Jaikiran Pai wrote:
>
> Hello Robert,
>
>> On 07/01/25 12:05 am, robert engels wrote:
>> ...
>> With a high performance http server, often the most expensive element is the
>> encoding/decoding/processing of the “headers” when accessing cached
>> r
extensive (like the SSL handling).
Regards,
Robert
> 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 fork of the JDK code.
>>
>> Would love to create a PR to move the cor
Hi,
Although, having the JDK specify an API for an http server has been awesome,
but I think an unfortunate design decision was to make Headers a concrete class
instead of an interface. I don’t think this can be easily changed now without
serious backwards compatibility issues.
With a high per
n 6, 2025, at 8:14 AM, Robert Engels wrote:
>
> But then I think http keep alive will break as the next request on that
> connection will be corrupted and hopefully rejected by the server.
>
> My point was that the test is not sending invalid requests intentionally and
> that sen
. HTTP/1.1 user agents MUST notify the user when an
> invalid length is received and detected."
>
> The latter part of this statement refers to a user agent's processing of a
> response
>
> From: net-dev on behalf of Robert Eng
ow raised a PR to address the test issue. As for the following part:
>
>> On 03/01/25 9:11 pm, robert engels wrote:
>> ...
>>
>> sends an invalid http request according to the specification here
>> https://datatracker.ietf.org/doc/html/rfc2616#section-4.4
>>
Thanks!
> On Jan 3, 2025, at 6:52 PM, Jaikiran Pai wrote:
>
> Hello Robert,
>
> This does indeed look like an issue in the test. I've filed
> https://bugs.openjdk.org/browse/JDK-8347000 to address this. Thank you for
> bringing it up here.
>
> -Jaikiran
&
Hi,
The jdk test B6361557 here
https://github.com/openjdk/jdk23u/blob/9101cc14972ce6bdeb966e67bcacc8b693c37d0a/test/jdk/com/sun/net/httpserver/bugs/B6361557.java#L68
sends an invalid http request according to the specification here
https://datatracker.ietf.org/doc/html/rfc2616#section-4.4
spec
think this should be fixed in the JDK, or at least
be marked that the JDK impl is non-compliant.
> On Dec 6, 2024, at 9:15 AM, robert engels wrote:
>
> I am confused though - I reviewed the robaho source code which came from the
> JDK, and the setAttribute is on the exchange, which is
I am confused though - I reviewed the robaho source code which came from the
JDK, and the setAttribute is on the exchange, which is per request, not per
context.
> On Dec 6, 2024, at 8:41 AM, robert engels wrote:
>
> In minor defense of the JDK (I am worried more about ambiguity) -
;>
>> I will add as maybe obvious context that the way the JDK currently
>> implements this is (I think, correct me if I am wrong) a security nightmare.
>> That it might not be obvious (or uniform across an ecosystem of
>> implementations) that exchange.setAttribute("C
Hi,I read the bug report. I don’t think this is sufficient. This is a specification so in order to have compliant behavior no matter the implementation there cannot be a different set of rules for the reference implementation vs others. So the api should be clarified in a non ambiguous manner and t
support connection upgradesIf this is a prerequisite, can this be added to the built-in server?On Mon, Dec 2, 2024 at 7:08 PM robert engels <reng...@ix.netcom.com> wrote:I am planning on adding it to the robaho version when I get some time. I think it is a lot of work for the jdk.server beca
I am planning on adding it to the robaho version when I get some time. I think
it is a lot of work for the jdk.server because it doesn’t support connection
upgrades - which I already added to the robaho version
https://github.com/robaho/httpserver
> On Dec 2, 2024, at 6:05 PM, Josiah Noel wrot
om <mailto:andy.boo...@gmail.com>
> Mobile: (979) 574-1089
>
>
> On Mon, Jul 29, 2024 at 3:57 PM robert engels <mailto:reng...@ix.netcom.com>> wrote:
> Yes, but normally you fork a worker process that tracks progress and scrapes
> N sites. If the worker process die
ge.
>
> On Mon, Jul 29, 2024, 3:52 PM robert engels <mailto:reng...@ix.netcom.com>> wrote:
> Isn’t the HttpClient almost always used to access other services?
>
> Why would a developer access a malicious service?
>
> I also think there are lots of ways for a service
Isn’t the HttpClient almost always used to access other services?
Why would a developer access a malicious service?
I also think there are lots of ways for a service to crash the client - .e.g it
could attempt to return a very large response - if the client uses a memory
buffered reader, it wil
On Wed, 1 May 2024 21:12:05 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional
> commits since the last re
On Sat, 15 Jun 2024 03:33:23 GMT, robert engels wrote:
>> robert engels has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'robaho/HttpExchange-api-change'
On Wed, 1 May 2024 21:12:05 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional
> commits since the last re
On Wed, 1 May 2024 21:12:05 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional
> commits since the last re
On Wed, 15 May 2024 04:20:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal 3 methods on `java.net.MulticastSocket`? This addresses
> https://bugs.openjdk.org/browse/JDK-8332181.
>
> As noted in that issue these methods have been d
On Wed, 15 May 2024 04:20:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal 3 methods on `java.net.MulticastSocket`? This addresses
> https://bugs.openjdk.org/browse/JDK-8332181.
>
> As noted in that issue these methods have been d
On Thu, 9 May 2024 16:44:23 GMT, SendaoYan wrote:
> Hi,
> The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm
> options. With -Xcomp jvm options, the jvm consumes a lot of time to compile
> the java code, but the timeout value is set to 5 second.
>
> I think it's 3 method t
On Sat, 6 Apr 2024 23:35:48 GMT, robert engels wrote:
> fix bug JDK-B6968351 by avoiding flush after response headers
This pull request has now been integrated.
Changeset: 02c95a6d
Author:robertengels
Committer: Daniel Fuchs
URL:
https://git.openjdk.org/jdk/com
On Fri, 3 May 2024 13:53:39 GMT, Ethan McCue wrote:
>> I think the solution is to document that the length must be greater than 0
>> or BBC an IllegalArgumentException is thrown.
>>
>> As I mention in the other comment - there is only really a single use for
>> this - streaming a file of know
On Fri, 3 May 2024 13:23:59 GMT, robert engels wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>> line 82:
>>
>>> 80: * @see #sendResponseHeaders(int, long)
>>> 81: * */
>>> 82: public static fin
On Fri, 3 May 2024 13:17:43 GMT, Ethan McCue wrote:
>> robert engels has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'robaho/HttpExchange-api-change'
On Wed, 1 May 2024 21:12:05 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional
> commits since the last re
On Wed, 1 May 2024 21:12:05 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with two additional
> commits since the last re
On Fri, 26 Apr 2024 15:37:13 GMT, robert engels wrote:
>> 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 re
> improve the HttpExchange api with documented constants and convenience
> methods to avoid common bugs
robert engels has updated the pull request incrementally with two additional
commits since the last revision:
- Merge remote-tracking branch 'robaho/HttpExchange-api-c
On Wed, 1 May 2024 15:10:22 GMT, Mark Sheppard wrote:
> It is not sending a chunked response, nor is it setting the Transfer-Encoding
> header to chunked for a chunked response
The javadoc was just a starting point - the method name is pretty clear imo
opinion what it does - but there are othe
On Wed, 1 May 2024 13:13:44 GMT, Bernd wrote:
> I agree that the sendResponse(NoContent) methods are good.
>
> I don’t think the “Headers” is particular clear - maybe “OS
> startChunkedResponse(int)” (but only if it actually encodes it chunked) and
> “OS startResponse(int status, long length)”
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
On Fri, 26 Apr 2024 15:37:13 GMT, robert engels wrote:
>> 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 re
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 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 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 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 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.
> 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
> 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
-
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
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://
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 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.
> 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 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 two additional
commits since the last revision:
- Merge remote-tracking branch 'robaho/B6968351' into B6968351
- no need for tcp nodelay a
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
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
> 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
> 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
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:
Update full name
-
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:
add https testing
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
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
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
> 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 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:
clean and move test based on PR review
-
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:
update copyright date
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18667/files
- new: ht
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
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 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: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: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 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 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 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
> 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 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
>>
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
> 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 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
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 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 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 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 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: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
> 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 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
1 - 100 of 149 matches
Mail list logo
