I'm running Apache 2.0.46 on RHEL (package name is httpd-2.0.46-32.ent).
I'm also running the latest mod_jk2 (2.0.4, compiled from source). I am
getting these errors very frequently in my apache log:
[Fri Apr 02 17:15:27 2004] [error] channelApr.receive(): Error receiving
message body -1 0
[Fri Ap
I'm running Apache 2.0.46 on RHEL (package name is httpd-2.0.46-32.ent).
I'm also running the latest mod_jk2 (2.0.4, compiled from source). I am
getting these errors very frequently in my apache log:
[Fri Apr 02 17:15:27 2004] [error] channelApr.receive(): Error receiving
message body -1 0
[Fri Ap
On my site, I have Apache 2.0 fronting Tomcat 4.1 using the mod_jk2
connector.
I'm trying to enable mod_deflate to automatically compress output from
Tomcat, using this line in my apache config:
AddOutputFilterByType DEFLATE text/html
But the DEFLATE filter is ignoring output from Tomcat, while
When I call from a Servlet:
response.setContentType("text/xml");
Tomcat changes the header to read:
Content-Type: text/xml;charset=ISO-8859-1
The ;charset is killing us interoping with another vendor and they can't
change their code. I've tried:
response.setLocale(null);
but it bombs Tomcat.
;my-page.jsp" links to other
JSP pages (e.g. using JSTL ), then the URL's generated will NOT
have the ":443" appended, and my session context between the two pages
is getting lost...
Thanks,
Bryan
On Fri, 2003-02-21 at 13:50, Bryan Field-Elliot wrote:
When a Connector
When a Connector's "redirectPort" kicks in to redirect the user to an
SSL protected version of the same URI, it is appending ":443" after the
DNS name of the server. This seems to be throwing off session tracking
later, since subsequent hyperlinks (to other JSP pages) don't have the
":443" in the U
It seems that every few months I have to pull up the reference on
mod_webapp (Apache side), and every time, I lose all my hair trying find
where the docs are, on apache.org or on jakarta.apache.org! Can someone
please tell me where the docs are?
Today, all I'm trying to find out, is the formal syn
Well, I was using JDK 1.3.1, and just for fun I tried booting up Tomcat
on JDK 1.4, and the problem below just vanished. It works now.
I'll report this as a bug (or at least, a request for documentation
addendum) in Bugzilla, if it isn't already...
On Fri, 2003-02-21 at 11:02, B
On Fri, 2003-02-21 at 11:13, Filip Hanik wrote:
make sure your "redirect" port is set to 443 and not 8443 in
server.xml
Filip
Thanks.. It is (set correctly to 443).
Bryan
On Fri, 2003-02-21 at 11:10, John Trollinger wrote:
CONFIDENTIAL will only allow it to be transported via https.
That's right. That's the effect I'm trying to achieve... When tomcat
receives a request for "/test.jsp" on port 80, have it redirect to port
443 with "https:". It's documented tha
I am (for the first time) playing with
CONFIDENTIAL.
My site is already working fine on ports 80 and 443 (SSL), I've just
never used this declarative security mechanism before.
I have this constraint applied to page "test.jsp" for me to test the
redirection.
Every time I hit the page, I get a
They are very different systems, but they work great together, and JBoss
even distributes a special version of JBoss bundled with (integrated
with) Tomcat.
In short - Tomcat is a "container" (basically, a server) for Java
Servlets and JSP pages. There are some extra bells and whistles thrown
in bu
I'm looking at the code for BaseAuthenticator and FormAuthenticator as a
basis for building my own.
It's not clear from the Javadocs where I configure Tomcat to use this
Valve...
1. Do I configure it by declaring a element in server.xml, or is
there a special (undocumented) element?
2. Do the
On Fri, 2003-02-14 at 15:16, Will Hartung wrote:
Let me head over to the corner, grab my stool and white, pointy
"Ignorant"
hat here as I butt in, but could what you want to be done be done
portably
using Filters? IMHO Filters are the most powerful aspect of the 2.3
spec as
I was discussing these issues with Jason Hunter, whose opinion is
quoted:
BFE> Craig was basically saying, don't assume any particular behavior
which
BFE> isn't specified in the spec. So, it's not safe to assume that it
will
BFE> be supported to POST to j_security_check a couple of requests
later,
On Thu, 2003-02-13 at 16:51, Craig R. McClanahan wrote:
First problem ... step 1 is only invoked when
* This request is from an unauthenticated user
* This request is for a protected resource
Now, consider the URL to which you're sending the SOAP message in
the
first
See below:
On Thu, 2003-02-13 at 16:14, Craig R. McClanahan wrote:
For Tomcat (at least), such a redirect will not work at all. The
magic
"j_security_check" URL is only enabled when the container did its
"save
the original request and display the form login page" trick. At
See my additional question at bottom:
On Sun, 2003-02-09 at 18:09, Craig R. McClanahan wrote:
> However, a Filter (Servlet 2.3)
> could parse this SAML
> response, and re-package the request parameters as a j_username
and a
> j_password (even though, really, the j_username is
On Sun, 2003-02-09 at 18:09, Craig R. McClanahan wrote:
Ah, if only it would ... it would require a change to the servlet
spec to
allow filters to perform "container managed security"
authentications.
>From a container writer's point of view, I get a little uneasy
thinking
Thanks for all your comments Craig,
I did a little more thinking since my original post.
First, to clarify - you mentioned that in this scenario, there really
isn't a local realm at all, since there is no local user database.
Actually there is, in the SAML model, there's a remote user database an
We are building out a toolkit for distributed single sign-on, using (today) standards
such as SAML and Liberty. While the guts of this toolkit are mostly finished, we
aren't actually populating the Subject/Principals list, and we'd like to add features
in that direction. I'm admittedly quite new
Hi,
I'm using Tomcat 4.0.4, and now, from sources, I'm trying to build
mod_webapp.
Every time I try "./configure" (with various option combinations), I get
this error:
configure: error: cannot find APRVARS file in
/root/src/jakarta-tomcat-connectors-4.0.4-src/webapp/apr
This is with jakarta-to
I'm having a very puzzling problem... I have a .war file which deploys
fine on one machine. On another machine however, when I deploy it in
Tomcat (4.0.3), I get:
java.util.zip.ZipException: invalid END header (bad central directory
offset)
the last interesting call in the stack trace is:
org.a
I'm having trouble getting Tomcat to reload my web application's
"web.xml" file, and wondering if there is an official word or FAQ on how
to do this? I've seen mention of Tomcat not reloading web.xml in the
archives, but I'm not sure if this is a bug, or improper use of the
Manager app, on my part
24 matches
Mail list logo
