Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jersey-dev] Limiting request size

Chiming in here as together with Maxim we solved a similar case in Jersey earlier this year. So here some tips:

(1) I would recommend using a ContainerRequestFilter instead of a ReaderInterceptor, as Filter's #abortWith method stops the processing chain at a much earlier, technical low level. ReaderInterceptors are good for intercepting the parsing of the data (on a semantic high level), but we do not need that level here. Cutting workflow ASAP is always good ("fast exit").

(2) I would recommend providing a configurable Property "maxPostSize" in the Application's configuration, so you can easily and externally configure the limit. Configurability is always good ("portable and flexible").

(3) I would recommend checking the Content-Length header FIRST. In case it is NOT spoofed, it is the most eager and most cheap way to abort any further processing AT ONCE without any measurable performance impact and without putting any more power consumed by downstream filters, interceptors and readers which OTHERWISE would start to process data USELESSLY on their own until the abort happens!

(4) I would recommend counting bytes explicitly using ContainerRequestContext.setInputStream(). You should check the original InputStream for #markSupported() because this allows you to #mark() + #read() + reset() a full bunch of bytes without implementing your own buffer or reading data twice explicity. If the stream does not support that, then usw either PushBackInputStream (to count explicitly) or some specialized FilterInputStream subclass ("LimitingInputStream").

(5) I would never put that into ANY MessageBodyReader as it is a safety aspect but not and aspect of neither the MediaType nor the entity class. Having things is the RIGHT place makes your code better to maintain, more stable and reusable! ("separation of concerns")!

(6) This makes sense only for some specific http verbs like POST or PUT. Your filter should check this initially and skip itself for GET and DELETE to prevent the overhead in those scenarios.

(7) Last but not least, this all makes sense only if your lower-level http server doesn't implement such a check on its own already! ;-)

Using these steps, there shouldn't be any measurable performance drawback, and the implementation is even portable and of common use. You should publish it to some open source project as a generic safety switch! :-)


-----Ursprüngliche Nachricht-----
Von: jersey-dev-bounces@xxxxxxxxxxx [mailto:jersey-dev-bounces@xxxxxxxxxxx] Im Auftrag von Martynas Jusevicius
Gesendet: Montag, 28. Dezember 2020 09:32
An: jersey developer discussions
Betreff: Re: [jersey-dev] Limiting request size

Thanks Jan.

Content-Length header can be spoofed, so I think I will need to be
counting bytes. I was thinking of doing it in the MessageBodyReader
where the request InputStream is consumed. But ReaderInterceptor
sounds cleaner.

How would I implement it without having to read the InputStream twice
though? In the ReaderInterceptor and then again in the

On Mon, Dec 28, 2020 at 12:36 AM Jan Supol <jan.supol@xxxxxxxxxx> wrote:
> Hi,
> No, Jersey does not specify a size limit on the server side for the
> input stream. The JAX-RS way is probably to specify ReaderInterceptor
> for this.
> -- Jan
> On 27.12.2020 23:57, Martynas Jusevičius wrote:
> > Hi,
> >
> > Is there a Jersey-specific way to specify a size limit when reading
> > request InputStream? For any content type, not just
> > multipart/form-data
> >
> > Or should I just go with the general SO suggestions such as a custom
> > counting InputStream subclass:
> >*30072143__;Iw!!GqivPVa7Brio!INptU6iAaHdzm5Z01fY0FX6OEkCjetrZahY7JngKUiWIIM2EyY96fRdL2VuxnhJI$
> >
> > I am using Tomcat and I know there's a maxPostSize setting but no, it
> > doesn't do this:
> >*22How*to*upload*Files*larger*than*2GB*22&o=newest&f=1__;JSsrKysrKyU!!GqivPVa7Brio!INptU6iAaHdzm5Z01fY0FX6OEkCjetrZahY7JngKUiWIIM2EyY96fRdL2UOpH8zd$
> >
> >
> > Martynas
> > _______________________________________________
> > jersey-dev mailing list
> > jersey-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit;!!GqivPVa7Brio!INptU6iAaHdzm5Z01fY0FX6OEkCjetrZahY7JngKUiWIIM2EyY96fRdL2TYch7zN$
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
jersey-dev mailing list
To unsubscribe from this list, visit

Back to the top