Re: Limiting multipart file upload sizes

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/30/20 16:51, Mark Thomas wrote:
> On 30/03/2020 21:45, Christopher Schultz wrote:
>> All,
>>
>> In my application under Tomcat 8.5.51, I have configured a
>> servlet to allow multipart/form-data submissions and I have added
>> this configuration as a part of the  config:
>>
>>  1048576 1049600 
>>
>> Without the  section, the upload does not work
>> at all, so I know I have added this in the right place.
>>
>> But I am able to upload files larger than 1MiB, and the data is
>> being given to the servlet. I was expecting an error to be sent
>> to the client (unlikely) or the data to be suppressed from the
>> servlet, or some kind of indication to the servlet code that the
>> upload was too big.
>>
>> The file I'm uploading as a test is 13658819 bytes, which is
>> greater than both 1048576 and 1049600.
>>
>> What am I missing, here?
>
> Are you reading the request body directly? That will bypass the
> size checks.

Nope. The order of calls in my servlet (actually a Struts action, but
there shouldn't be much in the way of interference, there) is:

getContentType
getAttributeNames (for debugging; I was expecting to
getAttribute   see an attribute saying "too big" or something)
getSession
getParameter (a few times)
getCharacterEncoding
getParts

The file definitely has data, in it, too. I'm uploading a file much
larger than expected just as a test, so I don't care what it is. I'm
uploading a tarball as a CSV and my servlet says "umm, that ain't CSV"
and logs the first few bytes of the file (and they aren't null or
empty or whatever I might expect if Tomcat were rejecting the upload).

> If that doesn't explain it, I'd fire up a remote debugger, debug
> through an upload and see why the size checks are skipped.

Time to figure out how to attach a debugger :) Fortunately, I've got
everything running on my own laptop, so I don't have to instrument a
server somewhere else.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CbecACgkQHPApP6U8
pFitFA/8CjVZrWTbxnSTp7EiNyCYDJWEZyWr8O4PAqZCp9csIwKoKEhAG087UHnc
g+Br8UPaH8DejOSCDu5X9HuTkjhtsDfu9l5lsnXcp1dTy4DzWfAPgdKi23i6o94y
BpAiRESMxT3PJ6mMbKae0auiPAVZ1K5WJ2m3rKC7dPGbqNlqaiAw1ZMoTWVfJNix
wAKTGEAIkJSo687qyoqTNEBjS0AeqFln2HvHkErHb4rt79uy1R0bL4QbnptED/h6
UihnUSqckn9F2R67f7duQeXQBvtmIFDVBegY0iZF/pyBnR4ifogv7V2QwWJikc8W
SkmMF9ZC2LWa0pXjvS4nVQNFv1Bg9tWYUZJFRqTr2lqqUkkEKqiWrGRNgmX8P/mx
6sNnGR+dc+q6L3Xp5ujdo85Hc46xuv7kUrW9SSpxkDCmhIiefPf+6HY5qh+1kvNW
vMn2Bz1PIK6+TbkgFFcJlrTns2kL9mea64dwyKDuJxdt2o/TLGJpA/Z6Uocieh9+
6cP3J3oy9WuuxlIq3q6jwnJRua41gDIXiEyLug4iVBCBJzGO7kUsvOUEze9L1r3N
IZWwLDCnPwg6QdWFrP9K7Kp7TqLHjvBF2hOLJHmCAAJlx21FIA5OscpVevKlVOuS
S0DvdunN8uj9biv/pueMZmFUl1XCvgLw+D8JpGEgAUHbdhJwIQw=
=pwCh
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Limiting multipart file upload sizes

[Mark Thomas]

On 30/03/2020 21:45, Christopher Schultz wrote:
> All,
> 
> In my application under Tomcat 8.5.51, I have configured a servlet to
> allow multipart/form-data submissions and I have added this
> configuration as a part of the  config:
> 
> 
>   1048576
>   1049600
> 
> 
> Without the  section, the upload does not work at
> all, so I know I have added this in the right place.
> 
> But I am able to upload files larger than 1MiB, and the data is being
> given to the servlet. I was expecting an error to be sent to the
> client (unlikely) or the data to be suppressed from the servlet, or
> some kind of indication to the servlet code that the upload was too big.
> 
> The file I'm uploading as a test is 13658819 bytes, which is greater
> than both 1048576 and 1049600.
> 
> What am I missing, here?

Are you reading the request body directly? That will bypass the size checks.

If that doesn't explain it, I'd fire up a remote debugger, debug through
an upload and see why the size checks are skipped.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Limiting multipart file upload sizes

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

In my application under Tomcat 8.5.51, I have configured a servlet to
allow multipart/form-data submissions and I have added this
configuration as a part of the  config:


  1048576
  1049600


Without the  section, the upload does not work at
all, so I know I have added this in the right place.

But I am able to upload files larger than 1MiB, and the data is being
given to the servlet. I was expecting an error to be sent to the
client (unlikely) or the data to be suppressed from the servlet, or
some kind of indication to the servlet code that the upload was too big.

The file I'm uploading as a test is 13658819 bytes, which is greater
than both 1048576 and 1049600.

What am I missing, here?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CWnEACgkQHPApP6U8
pFi1tRAAvs2wnlIgmfTeBpWWWFXh+vP+hOdgqW+7u/WiSb5viXvnYfoa+ezpiy7S
XHzctsBoQhs4Q+ErC1Ikz41btnuGbppnFe97mVplGDyca7aknxxdiLBP11azrD++
Ojn37bHjVFg1YzDFNDIJgG+yQC6/P0iFiMAUUsU1LM9oAOupLfiDyn+H6KLs/yV8
Z/NteP9GDgLvfNdmN1c+2gtAn0diRYOSvIOStXyS2Bsa1kueAu9zjIoHLMZExkdi
TrbmOBZV6/dR4LDP5/ZtIfuKA9urTIfMIpXqufyZh4A0Dk9QcDZMeh2t1txaAmEU
cRCwJkOIlkjq0GYAp8PvaTOSguvaw0om4d2z4V/l0Htov4bvW7h6Tzfx2LGXm2e8
KoqtGkQ9DSUclH3b/ik/Urwxoher24TnN4RcZlTamIJj7JBI5+n+x0YVzqn501Zz
VDTiuHUdNqKX1eqDTRjish0OFUKU6rUipnMZNzVQnKtgHqm5qHvwJan1r/chpQ1f
t4Fyujvs6N2q/K9N6gbvi+MY+hqlEyquOffuC6SY0dZGJkLXBffDqrMZyheOz+5h
RRxGqnrs7ZE2pme5KUdaYFmdDk1gUUph/ezudj1zuQNWVgx/W5T7J/+VuP2SAgoB
oKh5dHtRqCSPQq/Gv79OxxtzD/b5OcimvX2gGvq/OhCmMdYuVv0=
=kWh7
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eric,

On 3/27/20 16:39, Eric Robinson wrote:
> Thanks for all the feedback, André,  Christopher, and John. Let me
>  see if I can quickly answer everyone's comments.> Since there is a
> TCB for each connection, and the OS knows which TCBs are associated
> with which processes, I don't see any problem using the same local
> port on different sockets. When a packet arrives from a remote
> server, the stack looks at the full socket details, checks for a
> matching TCB, and routes the packet to the appropriate process.
> There's no confusion (except when using tools that don't show
> process names, like netstat without -p).> Using > 64K local source
> ports seems like a useful capability in high-load environments
> where tomcat is doing a lot of back-end access (i.e., where JSPs
> and class files frequently call back-end services). With hashing
> and indexing, having giant connection tables does not seem like an
> unrealistic amount of processing load to me. Linux-based stateful
> firewalls have to keep track of a lot more connections than that,
> with rule processing and even layer-7 inspection at the same time,
> on relatively low-powered hardware.

The likelihood that you end up with more than one connection with
identical source addr:port + dest addr+port is quite high in this
situation. You have to be VERY careful that you don't overlap or
you'll find that you have mass chaos on your hands.

> FYI, I don't have 1800 tomcat instances on one server. I have
> about 100 instances on each of 18 servers.

So is this just of academic interest to you, then? 100 client
connections per host doesn't seem like you have a problem to solve.

> That said, I agree that the real focus should probably be on the
> JDBC driver. I asked the question here because it seemed like a
> good place to start. Any ideas where I could go to chat with JDBC
> developers?
MySQL is open-source. They have forums, mailing lists, a public
bug-tracker, etc. You can also download the source and read through it
to find out how things are being done.

- -chris

>> -Original Message- From: Christopher Schultz
>>  Sent: Friday, March 27, 2020 1:42
>> PM To: users@tomcat.apache.org Subject: Re: Does Tomcat/Java get
>> around the problem of 64K maximum client source ports?
>>
> André,
>
> On 3/27/20 11:01, André Warnier (tomcat/perl) wrote:
 On 27.03.2020 14:27, André Warnier (tomcat/perl) wrote:
> On 26.03.2020 20:42, Eric Robinson wrote:
>>> -Original Message- From: Olaf Kock
>>>  Sent: Thursday, March 26, 2020
>>> 2:06 PM To: users@tomcat.apache.org Subject: Re: Does
>>> Tomcat/Java get around the problem of 64K maximum
>>> client source ports?
>>>
>>> Hi Eric,
>>>
>>> On 26.03.20 18:58, Eric Robinson wrote:
 Greetings,

 Many people say the maximum number of client ports is
 64K. However,
>>> TCP connections only require unique sockets, which are
>>> defined as...

 local_IP:local_port -> remote_ip:remote_port

 Theoretically, it is possible for a client process to
 keep using the same local
>>> source port, as long as the connections are to a
>>> unique destinations. For example on a local machine,
>>> the following connections should be possible...

 192.168.5.100:1400 -> 192.168.5.200:3306
 192.168.5.100:1400 -> 192.168.5.201:3306
 192.168.5.100:1400 -> 192.168.5.202:3306
 192.168.5.100:1400 -> 192.168.5.203:3306

 I've seen this demonstrated successfully here:

 https://serverfault.com/questions/326819/does-the-tcp-source-po
rt-
>

have


> -to-be-unique-per-host

 As someone on that page pointed out, while it is
 possible, it does not
>>> commonly occur in practice "because most TCP APIs don't
>>> provide a way to create more than one connection with
>>> the same source port, unless they have different source
>>> IP addresses." This leads to the 64K maximum client
>>> port range, but it is really a limitation of the APIs,
>>> not TCP.

 So how does tomcat handle things? Is it limited to a
 maximum 64K client
>>> source ports, or is it 64K per destination, as it
>>> should be?
>>>
>>> To be honest, I can't remember to have seen a web- or
>>> application server that accepts 64K concurrent
>>> connections at all, let alone to a single client.
>>>
>>> I can't come up with any reason to do so, I'd assume
>>> that there's a DOS attack if I get 100 concurrent
>>> incoming connections from a single IP, and a
>>> programming error if the server sets up more than 1K
>>> outgoing connections
>>>
>>> Maybe I'm missing the obvious, or have only
>>> administered meaningless installations, but I fail to
>>> see the real world 

Re: R: Support with error in launcher.log

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Luigi,

On 3/30/20 08:38, Luigi Tagliafierro wrote:
> we have already tried to implement the legacy cookie processor but
> with no result.

What did you actually do? What was the actual result?

I suspect that because:

1. The cookie domain is invalid
2. This error has been present "for a long time"
3. Nobody seems to have noticed

This means that your cookie has never been working and nobody cares
about it. Perhaps whatever is using this cookie can simply be removed
from your application?

- -chris

>  Da: calder 
> Inviato: lunedì 30 marzo 2020 13:14 A: Tomcat Users List
>  Cc: Alessio Torelli 
> Oggetto: Re: Support with error in launcher.log
>
> On Mon, Mar 30, 2020, 05:02 Luigi Tagliafierro
>  wrote:
>
>> Hi everybody,
>>
>> we are experiencing an error :  The bitbucket log
>> (/var/atlassian/bitbucket_home/log/launcher.log) constantly
>> repeats this error:
>>
>> "java.lang.IllegalArgumentException: An invalid domain
>>
>
>
> [.code.doxee.com] was specified for this cookie" .
>>
>
> Issue: the domain has a dot (.) at its beginning.
>
>
> The error has been present in the log for some time and continues
> to be.
>>
>> We contacted the support of atlassian, who after an analysis
>> suggested that we ask you about the error in question. Here the
>> link to the discussion, *and all the info, tests and steps we
>> took before contacting you* :
>> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-4
2041
>>
>>
>>
Our Tomcat version is: 8.5.29
>>
>> In attachment there is the complete error.
>>
>> We are waiting for an answer that can help you analyze or solve
>> the problem,
>>
>> Thanks a lot, Regards,
>>
>> Luigi
>>
>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CFncACgkQHPApP6U8
pFi5iQ/+MA+SH5fBwa6NMXU4z3yslP+6B9l9S5bI1WIDwsx7NfT8buuULekpVHv3
kZt3kmiNL0p1ViWynZJdbw8a+Rd1jub2YpjniYzpjEOdbGksctCka1PRdf5SJ01r
ZHq9cUvG1oEGoqWwbZoxo2dsKNi6uNOwBvb1WiIrVvvzU8ZWZVTo+TaUCmd1U684
3TfYejhQ7PPI//rElP7638XzlZdlk/odwYJSqui1t9bfCOcaWzI9Zut9WoI6+scs
tviakF7dlNM6JjFZVi/+gQiCCcF+xM2tfYEX39gHGedy0ZHYeJnnqSmwlwu9GqsQ
vVQr2j1CZCRqqjSIwGCvHg6U+YbpdgySKD0doutTTDNcGABN0KmWZxDY7HPAui5l
tWoByWy3Rt+7i9TPyJnEwcD2l0XNkmUwiLHAFTwPev7E2qQ1vxG3SU6nLd6SS5I/
a/hj2SGjSziwvDK9vCFSL2up/Eqc2A8VW2s63i9MPvx1PAeRmyyIyTe3BWPKpVe7
VuWK2rnVjLpD5jM5BhyJqpZyXWAYV0Qp8TwdNFBmSd4h7rHFH7ZgzXF3yVeWh3AA
NKg75j6IXk9a4Leju74rmi9iTpKUAxY4MabF9T0S+oPy0wlvZ3HyTQE1XanguUVQ
9WxoldF2NaZpf80v34GAjGHmqvhU1cN02m/kXUzO7PmhmYKmYb8=
=NhFz
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

R: Support with error in launcher.log

[Luigi Tagliafierro]

Hi,

we have already tried to implement the legacy cookie processor but with no 
result.

in the meantime we are considering some of the suggestions that have come so 
far,
Keep  help us!

thanks,

Luigi


Da: calder 
Inviato: lunedì 30 marzo 2020 13:14
A: Tomcat Users List 
Cc: Alessio Torelli 
Oggetto: Re: Support with error in launcher.log

On Mon, Mar 30, 2020, 05:02 Luigi Tagliafierro 
wrote:

> Hi everybody,
>
> we are experiencing an error :  The bitbucket log
> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
> error:
>
> "java.lang.IllegalArgumentException: An invalid domain
>


[.code.doxee.com] was specified for this cookie" .
>

Issue:
the domain has a dot (.) at its beginning.


The error has been present in the log for some time and continues to be.
>
> We contacted the support of atlassian, who after an analysis suggested
> that we ask you about the error in question.
> Here the link to the discussion, *and all the info, tests and steps we
> took before contacting you* :
> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>
> Our Tomcat version is: 8.5.29
>
> In attachment there is the complete error.
>
> We are waiting for an answer that can help you analyze or solve the
> problem,
>
> Thanks a lot,
> Regards,
>
> Luigi
>

>

Re: Support with error in launcher.log

[calder]

On Mon, Mar 30, 2020, 05:02 Luigi Tagliafierro 
wrote:

> Hi everybody,
>
> we are experiencing an error :  The bitbucket log
> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
> error:
>
> "java.lang.IllegalArgumentException: An invalid domain
>


[.code.doxee.com] was specified for this cookie" .
>

Issue:
the domain has a dot (.) at its beginning.


The error has been present in the log for some time and continues to be.
>
> We contacted the support of atlassian, who after an analysis suggested
> that we ask you about the error in question.
> Here the link to the discussion, *and all the info, tests and steps we
> took before contacting you* :
> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>
> Our Tomcat version is: 8.5.29
>
> In attachment there is the complete error.
>
> We are waiting for an answer that can help you analyze or solve the
> problem,
>
> Thanks a lot,
> Regards,
>
> Luigi
>

>

Re: Support with error in launcher.log

[Svetlin Zarev]

Hi,

We've had this error and it turned out to be due to the cookie processor.
According to RFC6265, the domain attribute of the cookie must not start
with a dot, so the new cookie processor rejects those cookies. Either
remove the starting dot from the domain attribute or use the legacy cookie
processor.

Kind regards,
Svetlin

На пн, 30.03.2020 г. в 13:22 Martin Grigorov  написа:

> Hi,
>
> On Mon, Mar 30, 2020 at 1:02 PM Luigi Tagliafierro <
> ltagliafie...@doxee.com> wrote:
>
>> Hi everybody,
>>
>> we are experiencing an error :  The bitbucket log
>> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
>> error:
>>
>> "java.lang.IllegalArgumentException: An invalid domain [.code.doxee.com]
>> was specified for this cookie" .
>>
>
> Is there a stacktrace with this error ?
> It would be good to see which class/method throws this exception.
>
>
>> The error has been present in the log for some time and continues to be.
>>
>> We contacted the support of atlassian, who after an analysis suggested
>> that we ask you about the error in question.
>> Here the link to the discussion, *and all the info, tests and steps we
>> took before contacting you* :
>> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>>
>> Our Tomcat version is: 8.5.29
>>
>
> Please try with a more recent version of Tomcat, e.g. 8.5.53.
>
>
>>
>> In attachment there is the complete error.
>>
>> We are waiting for an answer that can help you analyze or solve the
>> problem,
>>
>> Thanks a lot,
>> Regards,
>>
>> Luigi
>>
>>
>> [image: signature_1607051054]
>>
>>
>>
>> *Luigi Tagliafierro*
>>
>> *IX Team*
>>
>>
>> doxee.com 
>>
>> find us on:
>>
>> [image: signature_1049012399] [image:
>> signature_145818931] [image:
>> signature_816293899] 
>>
>>
>>
>>
>>
>> Questa email ed ogni eventuale allegato sono confidenziali.
>>
>> Se non siete il destinatario della presente ogni suo utilizzo è vietato.
>>
>> Le chiediamo di segnalare l’accaduto al  mittente e di cancellare il
>> messaggio.
>>
>> Questo messaggio è inviato da Doxee e non ha natura personale, le
>> informazioni contenute possono essere note al mittente o da altri suoi
>> collaboratori.
>>
>>
>>
>> This e-mail and any attachments are confidential.
>>
>> If you are not the intended recipient, you are hereby notified that any
>> use or distribution of this e-mail is strictly prohibited.
>>
>> Please contact the sender and delete this message from your system.
>>
>> We apologize for any inconvenience this may cause.
>>
>> This message is forwarded from Doxee and is not of a personal nature; the
>> information contained herein may be known by the sender and other employees
>> in the company.
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Support with error in launcher.log

[Martin Grigorov]

Hi,

On Mon, Mar 30, 2020 at 1:02 PM Luigi Tagliafierro 
wrote:

> Hi everybody,
>
> we are experiencing an error :  The bitbucket log
> (/var/atlassian/bitbucket_home/log/launcher.log) constantly repeats this
> error:
>
> "java.lang.IllegalArgumentException: An invalid domain [.code.doxee.com]
> was specified for this cookie" .
>

Is there a stacktrace with this error ?
It would be good to see which class/method throws this exception.


> The error has been present in the log for some time and continues to be.
>
> We contacted the support of atlassian, who after an analysis suggested
> that we ask you about the error in question.
> Here the link to the discussion, *and all the info, tests and steps we
> took before contacting you* :
> https://getsupport.atlassian.com/servicedesk/customer/portal/24/SSP-42041
>
> Our Tomcat version is: 8.5.29
>

Please try with a more recent version of Tomcat, e.g. 8.5.53.


>
> In attachment there is the complete error.
>
> We are waiting for an answer that can help you analyze or solve the
> problem,
>
> Thanks a lot,
> Regards,
>
> Luigi
>
>
> [image: signature_1607051054]
>
>
>
> *Luigi Tagliafierro*
>
> *IX Team*
>
>
> doxee.com 
>
> find us on:
>
> [image: signature_1049012399] [image:
> signature_145818931] [image:
> signature_816293899] 
>
>
>
>
>
> Questa email ed ogni eventuale allegato sono confidenziali.
>
> Se non siete il destinatario della presente ogni suo utilizzo è vietato.
>
> Le chiediamo di segnalare l’accaduto al  mittente e di cancellare il
> messaggio.
>
> Questo messaggio è inviato da Doxee e non ha natura personale, le
> informazioni contenute possono essere note al mittente o da altri suoi
> collaboratori.
>
>
>
> This e-mail and any attachments are confidential.
>
> If you are not the intended recipient, you are hereby notified that any
> use or distribution of this e-mail is strictly prohibited.
>
> Please contact the sender and delete this message from your system.
>
> We apologize for any inconvenience this may cause.
>
> This message is forwarded from Doxee and is not of a personal nature; the
> information contained herein may be known by the sender and other employees
> in the company.
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org