reiern70 commented on PR #856:
URL: https://github.com/apache/tomcat/pull/856#issuecomment-2890882787
> > IMHO what is described there is not what we need... because it has the
same problem we have now.
>
> Which is what, exactly?
The problem now is: 1) "someone" calls getParamaters 2) then tomcat parse
the parts 3) when wicket calls getInputStream if is already used.
What is proposed this is the way to set the listener:
```
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)
{
if(request-is-large)
{
MyProgressListener listener = new MyProgressListener(request);
request.getSession().addAttribute("progressListener", listener);
request.setProgressListener(listener);
}
}
```
Ok. Assume we do this in Wicket filter... Then
1. If there is no filter before wicket calling getParameters. The above will
work
2. If the is a filter before wicket that does call getParameters... then as
Tomcat 11 works now the above will not work because request will be already
"used".
What I propose here is:
- You pass to servlet/filter a progress listener factory.
https://github.com/apache/tomcat/pull/856/files#diff-56241da560fefa690696de7cd562438748aec8a07fe068e4bd0bb1bc49bf3b71R25.
- Tomcat calls this factory when multipart is processed (just before any
filters) in order to ask for a ProgressListener (see
https://github.com/apache/wicket/pull/1167/files#diff-35c9b71967f11dd14f923415ef75308af3202ef737e18027daf94e5c869ab8f9R31
a real example in a PR to Wicket code).
The above is safe because the listener is created by tomcat itself via the
factory. Thus, no matter who triggers the parsing of the parts the listener
will receive the notifications. Another problem with that design is:
1. You have an stack of filters. F1 -> F2 -> F3 and
2. F1 adds a Listener then F3 adds a listener (the replaces the previous
one)?
Thus... IMHO... this PR is also not correct. You Should maybe have some
stack of factories and each factory adds a Listener and then tomcat call each
of them in order.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
