On 28.03.2017 18:06, Scott, Derric T wrote:
On this list, it is preferred to not top-post, ...
No problem.
There are 2 different modules in Apache httpd which can be used for this :
mod_jk and mod_proxy_ajp.
Which one are you using, and can you give us a version?
OK... I inherited this, so don't know much about it ... but I don't see any
help in the log files. Looking
at the configs, I have (in /etc/httpd/conf.d/) both .... mod_jk.conf and
proxy_ajp.conf. It appears that
the mod_jk.conf is fleshed out and used. in the proxy_ajp.conf, only the
module load is uncommented,
there are no other commands in there. I have log files for mod_jk.conf as
well...
It looks like the apache might be 2.2.3. The mod_jk.so is dated Dec 17 2012.
((I will be replacing this server
at a later stage of this project, but not at first)).
If it is mod_jk that is being used, then in the Apache configuration files, you should
find at least one "JkMount" directive (or perhaps, but that is less frequently used, a
"SetHandler jakarta-servlet").
If it is mod_proxy_ajp being used, then there should be "ProxyPass ...
AJP://..." directives.
A note... I did a network snapshot of the old and new and then the "fixed" new.
The packet data in the
old (7.0.14 tomcat) POST packet looks practically the same in all cases. In
the new (7.0.69) case the
response from tomcat is a "RSP:SEND HEADERS:400 Bad Request"
Ah, so at least we know that the error is coming back from Tomcat, and is not generated
internally by the connector module under Apache httpd.
but the old one just proceeds with calling
the class and subsequent output. After I added a "name=submitbutton" to the "submit"
button, the "fixed" new had
a similar "POST" packet that was then followed immediately by a "REQ:Body" packet with
"Data: submitbutton=blahlah"
and the tomcat returned a "RSP:SEND HEADERS:200 OK"
If it is mod_jk, then there is a JkLogLevel directive, which may be set to get more
detailed logs of what is going on.
One problem with doing this via network tracing, is that the AJP protocol is partly
binary, so it is not always easy to decode what's going on.
The documentation of the AJP protocol (I think found on the Apache httpd website when
looking for mod_proxy_ajp) seems to indicate that the "Content-length" request header is
of particular importance. If it does not fit what the client is actually sending, that may
be a reason for your problem.
(The problem being that "Content-length" is probably one of these common headers whose
label is being binary-encoded in the AJP transmission).
Also, possibly, somewhere between Tomcat 7.0.14 and 7.0.69, the AJP Connector code in
Tomcat has been modified, perhaps to reject POST's with no content.
(In an intended or unintended way; after all, POSTs with no content aren't exactly your
standard thing, and could even be forbidden by the HTTP RFC (I haven't checked)).
The Tomcat change log on the website may give some clue there.
I have not checked any of these (re: $-job), so this is just guesses.
(But maybe here : Tomcat 7.0.21 (markt) -> Detect incomplete AJP messages and reject the
associated request if one is found. (markt) )
I don't have a lot of control over what versions I use ... I may only be
"allowed" to install
the current RedHat yum package.
Derric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
