You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2007/10/31 16:11:14 UTC
DO NOT REPLY [Bug 43753] New: - JkEnvVar and Limit of content length HTTP request POST
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
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
Platform: Macintosh
OS/Version: Mac OS X 10.4
Status: NEW
Severity: normal
Priority: P2
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)
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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
Re: VirtualHost inheritance (was Re: [Bug 43753] ...)
Posted by Rainer Jung <ra...@kippdata.de>.
Hi,
be careful: I added clone after 1.2.25 exaxctly because of the problem,
that the Apache API doesn't call the config create callback for a vhost,
if the vhost contains no config directives for some module.
In our situation we have the following assumptions:
- we don't want to automatically inherit JkMounts between vhosts.
That's documented and usually what you want. Content can be very
difficult between vhosts.
- we need a separate config structure for every vhost
This is why I introduced the clone. It's a copy without the mounts.
I also added an option JkMountCopyAll, 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).
Although I thought I had it fixed and tested, Jean-Frederic found a bug
with was_initialized which lets me think, that I got the "we already
initialized this vhost" markers wrong. It is still open for me to do the
final cleanup (correct markers for initialized state and cloned state)
and I might have an hour today to do so.
Regards,
Rainer
Mladen Turk schrieb:
> Ian Ward Comfort wrote:
>>
>> I don't know if this is intended behavior, or a bug in mod_jk, or even
>> a bug in Apache, but something seems amiss. Thoughts?
>>
>
> Your patch won't work.
> The real problem is in the initialization for vhosts where
> when there is *any* Jk directive the create_jk_config is called
> while where there isn't the clone_jk_config is called.
>
> clone_jk_config is bogus, and doesn't behave like it should
> (copy only the basic data and no mounts)
>
> Regards,
> Mladen
---------------------------------------------------------------------
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 Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On Nov 2, 2007, at 12:44 AM, Ian Ward Comfort wrote:
> I can't seem to find the repository location anywhere on the
> connectors page either...
Ah, found it on the Tomcat pages.
--
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 Mladen Turk <mt...@apache.org>.
Ian Ward Comfort wrote:
>>
>> clone_jk_config is bogus, and doesn't behave like it should
>> (copy only the basic data and no mounts)
>
> Was this function introduced since 1.2.25?
Yes, I was talking about trunk not 1.2.25
Regards,
Mladen
---------------------------------------------------------------------
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 Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On Nov 2, 2007, at 12:32 AM, Mladen Turk wrote:
> Ian Ward Comfort wrote:
>> I don't know if this is intended behavior, or a bug in mod_jk, or
>> even a bug in Apache, but something seems amiss. Thoughts?
>
> Your patch won't work.
No, not for this larger issue.
> The real problem is in the initialization for vhosts where
> when there is *any* Jk directive the create_jk_config is called
> while where there isn't the clone_jk_config is called.
>
> clone_jk_config is bogus, and doesn't behave like it should
> (copy only the basic data and no mounts)
Was this function introduced since 1.2.25? I don't see
clone_jk_config anywhere in my source tree. I can't seem to find the
repository location anywhere on the connectors page either...
--
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 Mladen Turk <mt...@apache.org>.
Ian Ward Comfort wrote:
>
> I don't know if this is intended behavior, or a bug in mod_jk, or even a
> bug in Apache, but something seems amiss. Thoughts?
>
Your patch won't work.
The real problem is in the initialization for vhosts where
when there is *any* Jk directive the create_jk_config is called
while where there isn't the clone_jk_config is called.
clone_jk_config is bogus, and doesn't behave like it should
(copy only the basic data and no mounts)
Regards,
Mladen
---------------------------------------------------------------------
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 Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On Nov 2, 2007, at 12:18 AM, Mladen Turk wrote:
> Ian Ward Comfort wrote:
>> I don't know if this is intended behavior, or a bug in mod_jk, or
>> even a bug in Apache, but something seems amiss. Thoughts?
>
> Right, this is bug indeed.
> If there is no Jk... directives the vhost conf is wrongly
> configured (seems that merge_jk_config is not evaluated)
>
> I'll check your patch, although it looks suspicious.
I agree. :)
Anyway, even if it doesn't break anything, the patch certainly
doesn't fix this underlying issue.
--
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 Mladen Turk <mt...@apache.org>.
Ian Ward Comfort wrote:
>
> I don't know if this is intended behavior, or a bug in mod_jk, or even a
> bug in Apache, but something seems amiss. Thoughts?
>
Right, this is bug indeed.
If there is no Jk... directives the vhost conf is wrongly
configured (seems that merge_jk_config is not evaluated)
I'll check your patch, although it looks suspicious.
Regards,
Mladen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
VirtualHost inheritance (was Re: [Bug 43753] ...)
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On Nov 1, 2007, at 8:14 PM, Ian Ward Comfort wrote:
> Here's one attempt at a patch, which fixes the problem in my
> limited testing. It modifies the code path as little as possible,
> since all I know about the intended behavior is what I've gleaned
> from a cursory audit.
In working on this bug I discovered a discrepancy (or perhaps just a
confusing ambiguity?) between mod_jk's behavior and its documentation
regarding VirtualHosts.
The docs specify that the default for JkMountCopy is "off", that is,
that JkMounts from a main server are by default not inherited by its
child VirtualHosts. But this is only true if there are mod_jk
directives within the VirtualHost container -- if there are no such
directives, JkMounts are inherited and it is as if JkMountCopy were
"on". The cause of this behavior is just what was underlying the
JkEnvVar bug; namely that when a VirtualHost has no mod_jk directives
then the server_rec objects for the main server and the virtual host
share a single jk_server_conf_t object.
I don't know if this is intended behavior, or a bug in mod_jk, or
even a bug in Apache, but something seems amiss. Thoughts?
--
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: [Bug 43753] New: - JkEnvVar and Limit of content length HTTP request POST
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
On Nov 1, 2007, at 7:33 AM, Rainer Jung wrote:
> I didn't have time to go into it, but thanks for the detailed
> report. We will fix this before 1.2.26.
Great, I'm glad to hear it.
> In case you have a patch to propose, that'll be a good starting point.
Here's one attempt at a patch, which fixes the problem in my limited
testing. It modifies the code path as little as possible, since all
I know about the intended behavior is what I've gleaned from a
cursory audit.
Beware, though, that this patch changes the semantics of the
was_initialized flag somewhat. This code sets it for all
jk_server_conf_t objects, even those for virtual hosts, on whom
init_jk() is never called. This should be safe since it seems that
the only other use of the flag is to check whether wc_close() must be
run, and I think that function is (must be?) idempotent.
Even if this is all correct, it might be better to add another flag
to jk_server_conf_t to indicate that environment-variable and options
initialization has occurred.
--- apache-2.0/mod_jk.c 2007-08-02 05:10:48.000000000 -0700
+++ apache-2.0/mod_jk.c 2007-11-01 17:35:01.000000000 -0700
@@ -2819,7 +2819,6 @@
conf = (jk_server_conf_t *)ap_get_module_config(s-
>module_config,
&jk_module);
if (!conf->was_initialized) {
- conf->was_initialized = JK_TRUE;
/* step through the servers and open each jk logfile
* and do additional post config initialization.
*/
@@ -2828,7 +2827,8 @@
&jk_module);
if (open_jklog(srv, pconf))
return HTTP_INTERNAL_SERVER_ERROR;
- if (sconf) {
+ if (sconf && !sconf->was_initialized) {
+ conf->was_initialized = JK_TRUE;
sconf->options &= ~sconf->exclude_options;
if (!uri_worker_map_alloc(&(sconf->uw_map),
sconf-
>uri_to_context, sconf->log))
--
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: [Bug 43753] New: - JkEnvVar and Limit of content length HTTP
request POST
Posted by Rainer Jung <ra...@kippdata.de>.
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: [Bug 43753] New: - JkEnvVar and Limit of content length HTTP request POST
Posted by Ian Ward Comfort <ic...@rescomp.stanford.edu>.
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
DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
------- Additional Comments From wp@artkode.com 2008-01-02 09:12 -------
No sorry, I have a permanently error without JKEnvVar : the version 1.2.26 is useless for me.
The HTTP error :
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="13
en" lang="e
en"><head><title>38 Object not found!</title>
<link rev="made" href="mailto:%0D%0A106%0D%0A**@******.com">
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
body { color: #000000; background-color: #FFFFFF; }
a:link { color: #0000CC; }
p, address {margin-left: 3em;}
span {font-size: smaller;}
/*]]>*/--></style></head><body>
<h1>
1b
Object not found!</h1>
<p>
39
The requested URL was not found on this server.
23
The link on the
<a href="97%0D%0Ahttp://www.***********.com/paiement/commande.html">referring
page</a> seems to be wrong or outdated. Please inform the author of
<a href="5e%0D%0Ahttp://www.***********.com/paiement/commande.html">that page</a>
about the error.
2
9
</p>
<p>
48
If you think this is a server error, please contact
the <a href="mailto:%0D%0A1e%0D%0A***@********.com">webmaster</a>.
11
</p>
<h2>Error
21
404</h2>
<address>
<a href="/">
25
www.***********.com</a><br>
9
<span>
21
Wed Jan 2 16:39:11 2008<br>
71
Apache/2.2.4 (Unix) mod_ssl/2.2.4 OpenSSL/0.9.7l DAV/2 PHP/5.2.1 mod_jk/1.2.26</span>
</address>
1
0
</body></html>
for the mod_jk.log, no bug found :
[Wed Jan 02 16:18:18 2008] [20325:2684415368] [info] init_jk::mod_jk.c (2825): mod_jk/1.2.26
initialized
for Tomcat catalina.out :
2 janv. 2008 16:58:01 org.apache.jk.common.ChannelSocket processConnection
GRAVE: Error, processing connection
java.lang.IndexOutOfBoundsException
at java.io.BufferedInputStream.read(BufferedInputStream.java:306)
at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:620)
at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:577)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:685)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:686)
at java.lang.Thread.run(Thread.java:613)
2 janv. 2008 16:58:02 org.apache.jk.common.MsgAjp processHeader
GRAVE: BAD packet signature 18245
the call of this page is a script PHP (it work with mod_jk 1.2.25 without JKEnvVar):
function locationPost($host,$uri,$data){
$header = 'POST http://'.$host.$uri.' HTTP/1.1'."\r\n";
$header .= 'Host: '.$host." \r\n";
$header .= 'User-Agent: '.$_SERVER['HTTP_USER_AGENT']." \r\n";
$header .= 'Referer: '.$_SERVER['HTTP_REFERER']." \r\n";
$header .= 'Content-Type: application/x-www-form-urlencoded'."\r\n";
$header .= 'Content-Length: '.strlen($data)."\r\n";
$header .= 'Connection: close'."\r\n\r\n";
$socket = fsockopen($host,80,$errno,$errstr);
if(!$socket) return '<strong>Error '.$errno.'</strong> '.$errstr;
$header .= $data;
fputs($socket,$header);
$response='';
while(!feof($socket)) $response.= fgets($socket, 4096);
fclose($socket);
return strstr($response,'<');
}
if(count($_POST)>0){
$data = "";
foreach($_POST as $key=>$val) {
if(!empty($data)) $data.= '&';
$data.= $key."=".urlencode($val);
}
echo locationPost($_SERVER['HTTP_HOST'],'/servlet/CyberplusRequest',$data);
exit;
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
------- Additional Comments From rainer.jung@kippdata.de 2008-01-02 09:39 -------
Could you please give us a little basic information:
- version of Tomcat
- Operating system for httpd and for tomcat server
- JK directives used for httpd, workers.properties
Which URL do you use to produce the problem?
What result did you expect and what was wrong with the result you received?
(for example you started this with error 413, but now it seems you have a
different problem?)
Please note: JkMounts do not get inhertited from the global server to virtual
hosts. If you use virtual hosts, please also give the information, how those
are structured, how they relate to your test case and your JK configuration.
If you can easily reproduce the problem with a single request, you can log
communication details between mod_jk and Tomcat by using JkLogLevel debug.
I interprete your last message as follows: the php script sends a POST request
to another httpd/mod_jk and the response you get is the error page you included
in your message. This error page looks like *not* coming from httpd but instead
from the backend behind JK (which is what?). With debig JkLogLevel, we could
more precisely see, if there is any problem between JK and the backend.
The backend error message you included looks a bit, like your backend is
outdated?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
------- Additional Comments From rainer.jung@kippdata.de 2007-11-03 11:16 -------
Could you please check, if the development snapshot of mod_jk found at
http://people.apache.org/~rjung/mod_jk-dev/
fixes the problem for you?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
rainer.jung@kippdata.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|Connectors |Native:JK
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
rainer.jung@kippdata.de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43753>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43753
------- Additional Comments From rainer.jung@kippdata.de 2008-01-01 21:31 -------
Could you please check, if the problem is fixed in the new version 1.2.26?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org