You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2011/01/21 18:50:18 UTC
Proposal: set default for Connector.allowCasualMultipartParsing to
true
All,
I've just committed a fix for
https://issues.apache.org/bugzilla/show_bug.cgi?id=49711
(HttpServletRequest#getParts() does not work in a Filter) with a new
configuration attribute on the <Connector> called
allowCasualMultipartParsing whose default value is "false". Please see
BZ for details.
I propose to make the default for this setting "true" unless
STRICT_SERVLET_COMPLIANCE is set to TRUE.
Any comments?
-chris
Re: Proposal: set default for Connector.allowCasualMultipartParsing
to true
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I'd opt for the default value to be true. I rather have usability than
spec compliance.
that's exactly what the STRICT_SERVLET_COMPLIANCE flag does, it opts for
usability,performance etc rather than spec compliance, and the default
value I believe is false on that flag.
Filip
On 01/21/2011 11:05 AM, Mark Thomas wrote:
> On 21/01/2011 17:57, Konstantin Kolinko wrote:
>
>> 2011/1/21 Christopher Schultz<ch...@christopherschultz.net>:
>>
>>> All,
>>>
>>> I've just committed a fix for
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=49711
>>> (HttpServletRequest#getParts() does not work in a Filter) with a new
>>> configuration attribute on the<Connector> called
>>> allowCasualMultipartParsing whose default value is "false". Please see
>>> BZ for details.
>>>
>>> I propose to make the default for this setting "true" unless
>>> STRICT_SERVLET_COMPLIANCE is set to TRUE.
>>>
>>> Any comments?
>>>
>>>
>> Why is it on Connector? Won't it be better to have it on Context?
>>
> Per Context seems reasonable to me.
>
> As far as defaults go, I'd rather non-spec compliant features were
> disabled by default. That way users have to explicitly enable them and
> can't complain about portability when they move their app to a different
> container that doesn't have the feature.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal: set default for Connector.allowCasualMultipartParsing
to true
Posted by Mark Thomas <ma...@apache.org>.
On 21/01/2011 17:57, Konstantin Kolinko wrote:
> 2011/1/21 Christopher Schultz <ch...@christopherschultz.net>:
>> All,
>>
>> I've just committed a fix for
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=49711
>> (HttpServletRequest#getParts() does not work in a Filter) with a new
>> configuration attribute on the <Connector> called
>> allowCasualMultipartParsing whose default value is "false". Please see
>> BZ for details.
>>
>> I propose to make the default for this setting "true" unless
>> STRICT_SERVLET_COMPLIANCE is set to TRUE.
>>
>> Any comments?
>>
>
> Why is it on Connector? Won't it be better to have it on Context?
Per Context seems reasonable to me.
As far as defaults go, I'd rather non-spec compliant features were
disabled by default. That way users have to explicitly enable them and
can't complain about portability when they move their app to a different
container that doesn't have the feature.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal: set default for Connector.allowCasualMultipartParsing
to true
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/1/21 Christopher Schultz <ch...@christopherschultz.net>:
> What about it's default setting?
>
I would opt for "false"
1) on the same grounds as Mark
2) what will happen with an older application that itself implements
file upload if this feature were enabled globally?
+ e.printStackTrace();
Use log.debug() or whatever, but not the above. No need for i18n.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal: set default for Connector.allowCasualMultipartParsing
to true
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Konstantin,
On 1/21/2011 12:57 PM, Konstantin Kolinko wrote:
> 2011/1/21 Christopher Schultz <ch...@christopherschultz.net>:
>> All,
>>
>> I've just committed a fix for
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=49711
>> (HttpServletRequest#getParts() does not work in a Filter) with a new
>> configuration attribute on the <Connector> called
>> allowCasualMultipartParsing whose default value is "false". Please see
>> BZ for details.
>>
>> I propose to make the default for this setting "true" unless
>> STRICT_SERVLET_COMPLIANCE is set to TRUE.
>>
>> Any comments?
>
>
> Why is it on Connector? Won't it be better to have it on Context?
Hmm... I guess I didn't even think about that. I can certainly move it
there, since you're right: it has nothing really to do with the connector.
What about it's default setting?
-chris
Re: Proposal: set default for Connector.allowCasualMultipartParsing
to true
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/1/21 Christopher Schultz <ch...@christopherschultz.net>:
> All,
>
> I've just committed a fix for
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49711
> (HttpServletRequest#getParts() does not work in a Filter) with a new
> configuration attribute on the <Connector> called
> allowCasualMultipartParsing whose default value is "false". Please see
> BZ for details.
>
> I propose to make the default for this setting "true" unless
> STRICT_SERVLET_COMPLIANCE is set to TRUE.
>
> Any comments?
>
Why is it on Connector? Won't it be better to have it on Context?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org