Re: [jersey-dev] Limiting request size

[Martynas Jusevičius <martynas@xxxxxxxxxxxxx>]

Thanks a lot Markus!

On Mon, Dec 28, 2020 at 10:12 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
>
> 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! :-)
>
> HTH
> -Markus
>
>
> -----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
> MessageBodyReader?
>
> 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:
> > > https://urldefense.com/v3/__https://stackoverflow.com/questions/15445504/copy-inputstream-abort-operation-if-size-exceeds-limit/30072143*30072143__;Iw!!GqivPVa7Brio!INptU6iAaHdzm5Z01fY0FX6OEkCjetrZahY7JngKUiWIIM2EyY96fRdL2VuxnhJI$
> > >
> > > I am using Tomcat and I know there's a maxPostSize setting but no, it
> > > doesn't do this:
> > > https://urldefense.com/v3/__https://www.mail-archive.com/search?l=users@xxxxxxxxxxxxxxxxx&q=subject:*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 https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!INptU6iAaHdzm5Z01fY0FX6OEkCjetrZahY7JngKUiWIIM2EyY96fRdL2TYch7zN$
> > _______________________________________________
> > jersey-dev mailing list
> > jersey-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev
>
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev