https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #26 from noodles ---
Tomcat version is 9.0.80;jdk version is 1.8.0_371
also using http/2, have change to encounter this error
```
I/O error while reading input message; nested exception is
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
noodles changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
Selim Emre Toy changed:
What|Removed |Added
CC||selimemre...@gmail.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
Mark Thomas changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
Boris Petrov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #23 from Boris Petrov ---
Well, I'm not sure what exactly you mean, but if you need more stacktraces,
here you go:
```
javax.ws.rs.ProcessingException: Failed to buffer the message content input
stream.
at
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #22 from Mark Thomas ---
9.0.26 will handle the behaviour in the original trace. That doesn't mean there
isn't more "unusual" behaviour that will trigger the issue.
--
You are receiving this mail because:
You are the assignee for
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #21 from Boris Petrov ---
Thanks for the tip, Mark. I'll try that tomorrow. But... is this setting still
needed? I thought that Tomcat 9.0.26 would remove the need for custom
configuration and would work out-of-the-box with Chrome
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #20 from Mark Thomas ---
9.0.26 fixed a typo in the attribute name. You want overheadDataThreshold in
9.0.26 onwards.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #19 from Boris Petrov ---
Mark, I'm observing a similar behavior on 9.0.26. The socket is closed even
when the `overheadDataThreadhold="0"` setting is set. Browser is Chromium
77.0.3865.90. I had to revert to 9.0.24 with that
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #17 from Mark Thomas ---
https://bugs.chromium.org/p/chromium/issues/detail?id=1000809
The root cause currently looks to be a combination of how Chrome's buffering
interacts with flow control windows that do not have an initial
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #16 from Mark Thomas ---
The 2852*5, 2124, 2852*5, 2124, 2852*5, 2124, 2852*5, 2123, 1, etc pattern
occurs (in Chrome at least) with a direct POST request with no libraries
present. That points to Chrome being responsible for the 1
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
Boris Petrov changed:
What|Removed |Added
Version|9.0.x |9.0.24
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #15 from Chen Levy ---
(In reply to Boris Petrov from comment #13)
> Chen Levy, if you could provide a simple sample project that, as you say,
> has no external dependencies and breaks with the default Tomcat
> configuration on the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #14 from Chen Levy ---
Created attachment 36744
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36744=edit
Simple project demonstrating multipart issue
--
You are receiving this mail because:
You are the assignee for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #13 from Boris Petrov ---
(In reply to Chen Levy from comment #11)
> I encountered a similar issue where multipart form submission resulted in
> none of the form parameters being visible from the servlet (no exception or
> error).
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #12 from Christopher Schultz ---
(In reply to Mark Thomas from comment #10)
> Which is why the threshold doesn't apply to DATA frames with the EOS (end of
> stream) flag set. Sending a small request body in a single DATA frame is
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #11 from Chen Levy ---
I encountered a similar issue where multipart form submission resulted in none
of the form parameters being visible from the servlet (no exception or error).
I created a small test project containing a single
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #10 from Mark Thomas ---
(In reply to Boris Petrov from comment #8)
> Hi, thanks for the detailed answer.
>
> There is no intermediate HTTP/2 proxy.
>
> Before I open an issue somewhere, could you please explain me something. I'm
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #9 from Christopher Schultz ---
(In reply to Mark Thomas from comment #7)
> Small HTTP/2 packets are inefficient. Lots of them are considered to be
> abusive and in some servers (not Tomcat) result in a DoS. Tomcat has
> expanded
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #8 from Boris Petrov ---
Hi, thanks for the detailed answer.
There is no intermediate HTTP/2 proxy.
Before I open an issue somewhere, could you please explain me something. I'm
not sure I fully understand what's going on but how
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #7 from Mark Thomas ---
Take a look at the following lines in the log:
Connection [1], Stream [7], Frame type [DATA], Flags [0], Payload size [...]
It looks like there is some buffering going on.
The first 6 data frames are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #6 from Boris Petrov ---
Created attachment 36736
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36736=edit
Dump of the POST request
This is a dump of the POST request for uploading a file (there should be 2 POST
multiform
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #5 from Mark Thomas ---
Correct. Tx.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail:
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #4 from Boris Petrov ---
Thank you for the support, Mark.
As I said, this happens with both the latest Chrome and Firefox, as well as
Firefox 47 (these are the three browsers I tested with). Only when using
HTTP/2. The client side
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #3 from Mark Thomas ---
The request has triggered the overhead protection because it looks abusive
(small non-final DATA frame). Setting overheadDataThreadhold to zero will
disable the specific protection triggered.
A debug trace
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #2 from Boris Petrov ---
Created attachment 36734
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36734=edit
Log
This is a dump of the logging for `org.apache.coyote.http2`.
--
You are receiving this mail because:
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #1 from Mark Thomas ---
Enable debug logging for org.apache.coyote.http2 and provide the output for a
single, failed request.
--
You are receiving this mail because:
You are the assignee for the bug.
30 matches
Mail list logo
