Tomcat 11 mutlipart strict configuration problem

2024-12-16 Thread anand raj
Hi all,

In Tomcat 11 a jersey Api multipart-formdata is registered with Multipart
feature.Also an inbound filter in front reading request.getparamater fails
with "unable to process parts as no multi-part configuration has been
provided."
In Tomcat 11 it fails.
In Tomcat 10 same setup works continuing parts as empty list.

Is this expected and valid change and if so any suggestion how to avoid
this?


Re: Tomcat 11 mutlipart strict configuration problem

2024-12-17 Thread anand raj
Thanks for replies yes we do have mismatch using jaxrs-Jersey Api and
Tomcat Filter causes issues so when choose to use Jersey filters it works
fine and makes sense after seeing the responses.

On Tue, 17 Dec, 2024, 12:51 am Christopher Schultz, <
ch...@christopherschultz.net> wrote:

> Mark,
>
> On 12/16/24 5:52 AM, Mark Thomas wrote:
> > On 16/12/2024 10:10, anand raj wrote:
> >> Hi all,
> >>
> >> In Tomcat 11 a jersey Api multipart-formdata is registered with
> Multipart
> >> feature.Also an inbound filter in front reading request.getparamater
> >> fails
> >> with "unable to process parts as no multi-part configuration has been
> >> provided."
> >> In Tomcat 11 it fails.
> >> In Tomcat 10 same setup works continuing parts as empty list.
> >>
> >> Is this expected
> >
> > Yes.
> >
> >> and valid change
> >
> > Yes.
> >
> > Parameter parsing in the Servlet spec has been tightened up to fail with
> > an exception rather than to ignore errors and carry on.
>
> More specifically, these requests were /actually failing/ in Tomcat 10
> and not producing any warnings or errors. So the difference is that you
> know about the failures, now.
>
> >> and if so any suggestion how to avoid this?
> >
> > If you want Tomcat to parse the form data then either:
> >
> > - configure the target servlet to support multi-part
> >
> > or
> >
> > - set allowCasualMultipartParsing="true" on the Context
> >
> >
> > If you don't want Tomcat to parse the form data:
> >
> > - don't call any of the getParameter*() methods
> > - read the body using getInputStream()
> > - parse the body manually.
>
> -chris
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Tomcat 10 usage and necessity of --add-opens

2025-01-23 Thread anand raj
Hi all,

In Tomcat 10 there is --add-opens added default and does this mean Tomcat
required to access these .Also document information on what all are
accessed which requires these will be helpful.



Thanks,
ANANDARAJ N


Re: Tomcat 10 usage and necessity of --add-opens

2025-01-24 Thread anand raj
Hi all,
is memory leak detection not optional ? Also does adding --add-opens pose
any security risk or concern ?

On Thu, 23 Jan, 2025, 8:25 pm Mark Thomas,  wrote:

> On 23/01/2025 14:42, anand raj wrote:
> > Hi all,
> >
> > In Tomcat 10 there is --add-opens added default and does this mean Tomcat
> > required to access these.
>
> Yes.
>
> > Also document information on what all are
> > accessed which requires these will be helpful.
>
> Generally to implement the memory leak detection and prevention on web
> application stop.
>
> git blame (or the equivalent GitHub UI) will point you towards the
> individual commits. The commit messages should provide more detail
> including links to any associated bug reports.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>