You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2007/11/01 15:33:01 UTC

Re: [Bug 43753] New: - JkEnvVar and Limit of content length HTTP request POST

Hi Ian,

I didn't have time to go into it, but thanks for the detailed report. We
will fix this before 1.2.26. In case you have a patch to propose,
that'll be a good starting point.

Regards,

Rainer

Ian Ward Comfort schrieb:
> On Oct 23, 2007, at 2:51 AM, Ian Ward Comfort wrote:
>> On Oct 22, 2007, at 11:24 PM, Mladen Turk wrote:
>>>> By adding some additional instrumentation to the code, I can see
>>>> that each AJP packet is constructed with ((1 + 17) * 13) = 234
>>>> envvar attributes -- the whole set of attributes is appended 18
>>>> times in succession.  (Often this overflows the default maximum
>>>> packet size.)
>>>
>>> Can you use JkLogLevel debug and attach the packet dumps as well as
>>> the the config?
> 
>> [1] http://rescomp.stanford.edu/~icomfort/jk/logging.patch
>> [2] http://rescomp.stanford.edu/~icomfort/jk/httpd.conf
>> [3] http://rescomp.stanford.edu/~icomfort/jk/workers.properties
>> [4] http://rescomp.stanford.edu/~icomfort/jk/mod_jk_log
>> [5] http://rescomp.stanford.edu/~icomfort/jk/ajp.dump
> 
> On Oct 31, 2007, at 8:11 AM, bugzilla@apache.org wrote:
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
>>
>>            Summary: JkEnvVar and Limit of content length HTTP request
>> POST
>>            Product: Tomcat 6
>>            Version: 6.0.10
> 
>>          Component: Connectors
>>         AssignedTo: tomcat-dev@jakarta.apache.org
>>         ReportedBy: wp@artkode.com
> 
>> In the httpd.conf Apache 2.0, JkEnvVar is assigned to SERVER_NAME
>> When I add a virtualhost with a new ServerName, I have immediately an
>> HTTP error :
>>
>> Error 413 Request entity too large! The POST method does not allow the
>> data transmitted, or the data volume exceeds the capacity limit.
>>
>> I suppose that error is linked to the number of declaration ServerName
>> (60)
> 
> These sound like the same issue to me.  Has anyone had a chance to look
> at the code?
> 
> I could take a stab at a patch quickly, but I'd certainly want someone
> more familiar with the codebase to review it.
> 
> -- 
> Ian Ward Comfort <ic...@rescomp.stanford.edu>
> System Administrator, Student Computing, Stanford University

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

Posted by Rainer Jung <ra...@kippdata.de>.

Mladen Turk schrieb:
> Rainer Jung wrote:
>> Hi,
>>
>> be careful:
> 
> OK :)
> 
>>
>> I also added an option JkMountCopyAll,
> 
> OK, but clone is called when there is no "JkMountCopy All" defined
> if (sconf && sconf->was_initialized == JK_TRUE && jk_mount_copy_all ==
> JK_FALSE) {
>     clone_jk_config
> 
> So if there is *no* module directives and JkMountCopy All is not defined
> the clone_jk_config is still called (without mounts but with copied
> envvars).

Yes, at the moment I don't trust the state handling ...
I still need to check and fix that.

To not clone if JkMountCopyAll is set is OK, because then we
automatically use the same config struct, as the parent vhost. httpd
simply does not call our create structure in this case and instead
inhertis the full structure automatically.

We only want to clone (and empty the JkMounts), if we have an "empty"
vhost, but don't want to inherit the JkMounts (the latter being the
default).

>> which automatically puts a
>> JkMountCopy into every vhost and saves memory, because we then do not
>> clone but instead share the config struct (if no other jk directives are
>> in the vhost).
> 
> But they use different apr_pools with different lifetime, so that might
> be the problem later. Cloned configs although allocated don't register
> pool cleanup

OK. Needs fixing.

> Anyhow the envvar tables should be NULLed in clone, cause
> merge will later concatenate them for each vhost.

That's easy and most likely the point. Then we have the same question here:

- we shouldn't inherit JkEnvVars by default between vhosts
- we could have an option to inherit them (like JkEnvVarCopy) per vhost
and one to inherit them globally (JkEnvVarCopyAll).

Why is globally ineriting interesting in its own: if people use a lot of
vhosts (hundreds), with global inheritance of everything (mounts and
vars), they can automatically share the same jk config structure and
save quite some memory.

> Regards,
> Mladen.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: VirtualHost inheritance (was Re: [Bug 43753] ...)

Posted by Mladen Turk <mt...@apache.org>.

Rainer Jung wrote:
> Hi,
> 
> be careful:

OK :)

> 
> I also added an option JkMountCopyAll,

OK, but clone is called when there is no "JkMountCopy All" defined
if (sconf && sconf->was_initialized == JK_TRUE && jk_mount_copy_all == JK_FALSE) {
	clone_jk_config

So if there is *no* module directives and JkMountCopy All is not defined
the clone_jk_config is still called (without mounts but with copied
envvars).

> which automatically puts a
> JkMountCopy into every vhost and saves memory, because we then do not
> clone but instead share the config struct (if no other jk directives are
> in the vhost).

But they use different apr_pools with different lifetime, so that might
be the problem later. Cloned configs although allocated don't register
pool cleanup

Anyhow the envvar tables should be NULLed in clone, cause
merge will later concatenate them for each vhost.

Regards,
Mladen.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org