On 17.02.2011 11:58, Mark Thomas wrote:
Given this, I am leaning even more towards just fixing the original
issue that the connection is not dropped when the request exceeds the
upload limit and leaving the rest of the behaviour unchanged.
Getting back to this (and sorry for the pause): What's
All,
On 2/17/2011 5:41 AM, Mark Thomas wrote:
> On 17/02/2011 10:30, Rainer Jung wrote:
>> On 10.02.2011 18:44, Mark Thomas wrote:
>> Any hints about where to add stuff to the docs? Are people fine with
>> making it controllable via the request attribute?
>
> I'm not particularly comfortable with
On 2/17/2011 4:41 AM, Mark Thomas wrote:
>
> I'm not particularly comfortable with this. I'm having a hard time
> coming up with a use case where some requests are swallowed and some are
> not. I think I'd prefer a per Connector or per Context attribute. I need
> to read the right part of the HTTP
On 17.02.2011 11:58, Mark Thomas wrote:
On 17/02/2011 10:41, Mark Thomas wrote:
On 17/02/2011 10:30, Rainer Jung wrote:
On 10.02.2011 18:44, Mark Thomas wrote:
On 10/02/2011 13:04, Rainer Jung wrote:
Servlet 3 standardizes file uploads. It contains the ability to limit on
request size, pretty
On 17/02/2011 10:41, Mark Thomas wrote:
> On 17/02/2011 10:30, Rainer Jung wrote:
>> On 10.02.2011 18:44, Mark Thomas wrote:
>>> On 10/02/2011 13:04, Rainer Jung wrote:
Servlet 3 standardizes file uploads. It contains the ability to limit on
request size, pretty much the same as commons f
On 17/02/2011 10:30, Rainer Jung wrote:
> On 10.02.2011 18:44, Mark Thomas wrote:
>> On 10/02/2011 13:04, Rainer Jung wrote:
>>> Servlet 3 standardizes file uploads. It contains the ability to limit on
>>> request size, pretty much the same as commons fileupload supported for
>>> many years.
>>>
>>
On 10.02.2011 18:44, Mark Thomas wrote:
On 10/02/2011 13:04, Rainer Jung wrote:
Servlet 3 standardizes file uploads. It contains the ability to limit on
request size, pretty much the same as commons fileupload supported for
many years.
It seems when this conditions triggers the rest of the requ
Mark,
On 2/11/2011 4:37 AM, Mark Thomas wrote:
> On 10/02/2011 21:32, Christopher Schultz wrote:
>> Rainer,
>>
>> On 2/10/2011 8:04 AM, Rainer Jung wrote:
>>> It seems there's still no server-side prevention against huge uploads
>>> possible. The upload is not put into memory, but the thread is on
William,
On 2/10/2011 4:51 PM, William A. Rowe Jr. wrote:
> On 2/10/2011 7:04 AM, Rainer Jung wrote:
>> Servlet 3 standardizes file uploads. It contains the ability to limit on
>> request size,
>> pretty much the same as commons fileupload supported for many years.
>>
>> It seems when this condit
On 10.02.2011 18:00, Filip Hanik - Dev Lists wrote:
On 2/10/2011 6:04 AM, Rainer Jung wrote:
Servlet 3 standardizes file uploads. It contains the ability to limit
on request size, pretty much the same as commons fileupload supported
for many years.
It seems when this conditions triggers the res
On 10/02/2011 21:32, Christopher Schultz wrote:
> Rainer,
>
> On 2/10/2011 8:04 AM, Rainer Jung wrote:
>> It seems there's still no server-side prevention against huge uploads
>> possible. The upload is not put into memory, but the thread is only
>> freed once the whole request body is read. Shoul
On 2/10/2011 7:04 AM, Rainer Jung wrote:
> Servlet 3 standardizes file uploads. It contains the ability to limit on
> request size,
> pretty much the same as commons fileupload supported for many years.
>
> It seems when this conditions triggers the rest of the request inout stream
> is still
>
Rainer,
On 2/10/2011 8:04 AM, Rainer Jung wrote:
> It seems there's still no server-side prevention against huge uploads
> possible. The upload is not put into memory, but the thread is only
> freed once the whole request body is read. Shouldn't Tomcat ignore the
> rest of data and close the conne
On 10/02/2011 13:04, Rainer Jung wrote:
> Servlet 3 standardizes file uploads. It contains the ability to limit on
> request size, pretty much the same as commons fileupload supported for
> many years.
>
> It seems when this conditions triggers the rest of the request inout
> stream is still drain
On 2/10/2011 6:04 AM, Rainer Jung wrote:
Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload
supported for many years.
It seems when this conditions triggers the rest of the request inout stream is still drained at th
Servlet 3 standardizes file uploads. It contains the ability to limit on
request size, pretty much the same as commons fileupload supported for
many years.
It seems when this conditions triggers the rest of the request inout
stream is still drained at the end of the request. swallowInput is no
16 matches
Mail list logo
