-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
7026262: HttpServer: improve handling of finished HTTP exchanges #13157
Conversation
👋 Welcome back djelinski! A progress list of the required criteria for merging this PR into |
@djelinski The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java
Outdated
Show resolved
Hide resolved
if (zerolength) { | ||
// WriteFinishedEvent was sent already; nothing to do | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be more correct to have sendResponseHeader close the output stream, and let the output stream close
generate the write event, rather than having sendResponseHeader generate the event and not doing anything here? Or would there be an issue with the case where the stream is chunked output stream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sendResponseStream
could close the stream when called with length = -1; the output stream is always fixed length in that case. I'd need to modify this class to accept zero-length writes even when closed, but I think there's a precedent for that already. Will look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was just a suggestion - I was a bit bothered with the hidden interaction between FixedLengthOutputStream and sendResponseHeaders here, where FixedLengthOutputStream has to trust that sendResponseHeaders has sent the event. It looked strange. Maybe there are other possibilities - like e.g a ZeroLengthOutputStream :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed sendResponseHeaders
to close the exchange, and I like the result much better.
ExceptionKeepAlive
test no longer needs to explicitly close the request body before sending the response - exchange's close
takes care of that.
Let me know what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder should we move the code that sends the write finished event in this case to here? I agree this code looks pretty strange. Never mind. I see this has changed in the new revision.
eof = (remaining == 0); | ||
if (eof) { | ||
throw new StreamClosedException(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe before checking closed
we should just return if len == 0? (and throw if < 0 BTW)
Possibly consider doing the same for ChunkedOutputStream.
Also ChunkedOutputStream throws StreamClosedException() when closed
is true. Not sure why we're throwing plain IO here. Or rather - not sure why we have StreamClosedException() in the first place, it doesn't seem to be handled specially anywhere, and it can reach user code (code calling write()), and it's not a public exception - so maybe it should be removed altogether and replaced with IOException("stream closed") everywhere? But getting rid of StreamClosedException may be a task for another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. Filed JDK-8304873 to remove StreamClosedException
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks much cleaner. It would be good to get @Michael-Mc-Mahon review too. But if all tests are passing and stable, it sounds good to me.
@djelinski This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 33 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me
Objects.checkFromIndexSize(off, len, b.length); | ||
if (len == 0) { | ||
return; | ||
} | ||
if (closed) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially I didnt think the above was a great idea as OutputStream.write is spec'd to throw IOE if the stream is closed, but it appears that some commonly used OutputStream classes are tolerant of zero length writes
/integrate |
Going to push as commit a5ffa07.
Your commit was automatically rebased without conflicts. |
@djelinski Pushed as commit a5ffa07. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This patch fixes the following issues with HttpHandler exception handling:
getResponseBody
is now usable even if the response has zero-length body. Writing any data to the stream will still fail, but zero-length writes and closing the stream will now succeed.ServerImpl.Exchange.reject
now sends aConnection: close
header in addition to closing the connectionThe test
B8293562
had to be adjusted to avoidConnection: close
.Additionally, while I was looking for a good test to copy from, I found and fixed a bug in test
B5045306
.The new tests are passing with this patch, failing without it. Tier 1-3 clean.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13157/head:pull/13157
$ git checkout pull/13157
Update a local copy of the PR:
$ git checkout pull/13157
$ git pull https://git.openjdk.org/jdk.git pull/13157/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13157
View PR using the GUI difftool:
$ git pr show -t 13157
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13157.diff