[UNDERTOW-2157] UndertowOutputStream: behaviour discrepancies, clarify contract, fix bug #1372
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
j-baker
commented
Sep 6, 2022
servlet/src/main/java/io/undertow/servlet/spec/ServletOutputStreamImpl.java
Show resolved
Hide resolved
j-baker
force-pushed
the
jbaker/uos_fix
branch
from
0401740 to
54805a6
Compare
j-baker
commented
Sep 6, 2022
Member
|
thanks for your PR @j-baker ! It will be reviewed shortly and, if approved, added to 2.3.0.Beta2 or 2.3.0.Final. |
fl4via
added
the
new feature / API change
fl4via
requested changes
Oct 11, 2022
servlet/src/main/java/io/undertow/servlet/spec/ServletOutputStreamImpl.java
Show resolved
Hide resolved
fl4via
added
the
waiting PR update
fl4via
force-pushed
the
jbaker/uos_fix
branch
from
54805a6 to
4ae76e0
Compare
Member
|
Because we did not get a response in a timely manner, I will be updating this PR to incorporate the feedback so it can be merged. |
Member
|
After somethought, I decided to remove the new method and keep the fixes. The reason for this is that, with this, it can be backported to old branches, and there is no need for a new method. The interface is used internally. If someone raises a need for a new method, then we will of course introduce it. |
fl4via
force-pushed
the
jbaker/uos_fix
branch
from
2818d5b to
bd6dcce
Compare
fl4via
approved these changes
Oct 16, 2025
fl4via
added
waiting CI check
fl4via
force-pushed
the
jbaker/uos_fix
branch
3 times, most recently
from
592a9e1 to
c9e6c9c
Compare
…y contract, fix bug BufferedWriteableOutputStream is currently implemented by: 1. UndertowOutputStream 2. ServletOutputStreamImpl These have two different behaviours. In UndertowOutputStream, I _believe_ that if the input FileChannel's position is 0, it transfers the whole channel, and if it's non-zero, it crashes. In ServletOutputStreamImpl, I think the behaviour is something more like: 1. If there is no listener set, transfer the bytes between the current position and end of file. 2. If there is a listener set, transfer the bytes between the current position and end of file, setting the input channel's position as well. This PR makes the behaviour be more consistent and adds a new, clearer API, deprecating the old one. 1. Clarify the contract of BufferedWriteableOutputStream.transferTo as being the ServletOutputStreamImpl's behaviour, since it has a superset of the UndertowOutputStream's functionality. 2. Never set the position of the input channel in ServletOutputStreamImpl, since it leads to inconsistent behaviour depending on whether the listener is set and seems incongruent with the contract of the underlying FileChannel apis. 3. Add an explicit `transferFrom(FileChannel source, long startPosition, long count)` method to the interface and implement in both implementations. In theory there is a breaking behaviour change for the user who is relying on their FileChannel's position being set to EOF as a side-effect of the change. Internally to Undertow there is no problem here.
Signed-off-by: Flavia Rainone <[email protected]>
…oved Signed-off-by: Flavia Rainone <[email protected]>
fl4via
force-pushed
the
jbaker/uos_fix
branch
from
c9e6c9c to
3494607
Compare
fl4via
approved these changes
Oct 16, 2025
fl4via
added
the
next release
This was referenced Oct 27, 2025
This was referenced Oct 27, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Jira: https://issues.redhat.com/browse/UNDERTOW-2157
2.2.x PR: #1829
2.3.x PR: #1830
2.4.x PR: #1831
undertow-ee PR: undertow-io/undertow-ee#25
BufferedWriteableOutputStream is currently implemented by:
These have two different behaviours. In UndertowOutputStream, I believe that if the input FileChannel's position is 0, it transfers the whole channel, and if it's non-zero, it crashes.
In ServletOutputStreamImpl, I think the behaviour is something more like:
This PR makes the behaviour be more consistent and adds a new, clearer API, deprecating the old one.
transferFrom(FileChannel source, long startPosition, long count)method to the interface and implement in both implementations. The current 'transferFrom' method has an extremely confusing signature - it's defined to transfer the rest of the file, which seems unnecessarily specific for such a generic interface.In theory there is a breaking behaviour change for the user who is relying on their FileChannel's position being set to EOF as a side-effect of the change. Internally to Undertow there is no problem here but obviously this is an API. In my head this is a bugfix but I'd be happy to maintain the present behaviour - I just don't know enough about the 'intended' contract.