DO NOT REPLY [Bug 38329] New: - isapi_redirect.dll returns application not available when application stopped in Manager

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38329

   Summary: isapi_redirect.dll returns application not available
when application stopped in Manager
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Windows Server 2003
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When using the load balancer worker and on one of the clustered host the 
application is stopped (via Manager or the like) isapi_redirect.dll (version 
1.2.15) will return application unavailable.

I would like to suggest an enhancement that isapi_redirect.dll check other 
host in the worker.list before returning this message.

Kevin

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

UserManager should be added

[Jack]

In order to add a new user to a web-app, since specification 2.4 doesn't 
cover this, web-app might have to take care of this. User information will 
be used by web-app anyway, the web-app keeps many information about the 
user. Keep its password is not difficult at all, and it is easier for the 
web-app to change password for the user. In case the user uses a 
certificate, the web-app might also use the certificate anyway. So the 
UserManager will be used by both the web-app Container & the web-app.



There are 3 types user contexts:

1. Engine user context (tomcat-userx.xml, should not mix up with host & 
web-app user context. At present, they all mixed up.)

2. Host user context (Users defined in a host user context will be available 
to all web-apps in this host.)

3. Web-app user context



Under the Engine element, add a Users element (EngineUserContext). Its 
content is the content of tomcat-users.xml, and tomcat-users.xml could be 
eliminate, or an attribute in Users link to tomcat-users.xml.

Under each Host element, there could be a Users element (HostUserContext), 
too.

In the context.xml for each web-app, there could be a Users element 
(WebAppUserContext), too.



In Host Users & web-app users elements, the possible attributes are:



scope=host|engine whether users information available to other context. 
"host" is the default value.

useHost=yes|noUsing users defined in the host context. default: yes

useOtherWebApp=yes|no   Using users defined in other web-app exposed to the 
same host. default: yes

useOtherHost=yes|noUsing users defined in other host exposed to the same 
engine. default: no

clientAuth

keystoreFile

keystorePass

keystoreType

truststoreFile

truststorePass

truststoreType



The last 6 attributes of Connector element should become attributes of Users 
elements since they are all UserContext properties.



"clientAuth" is configed in the login-config element in web.xml. If the 
client is requesting a server resource that requires client authentication, 
the server requests the client's certificate. However, it could also be put 
on Users element.



Single Signon

At present, single signon is done with a valve.



For a user crosses a web-app (1) to another web-app (2) to access a 
constrained resource, the authorizer(Realm) will call the UserManager 
whether the user has a role for the resource. And the UserManager will 
consult the user context of the web-app 2 to check whether it accept users 
from web-app 1. If yes, and the user is authenticated, then the container 
doesn't have to ask the user do authentication again.



This will be more logic than the original implementation with valve.


[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

an example of Users element

[Jack]

Furthermore, the original Realm element could be moved into Users element. 
The Users element should be able to include several Realm elements, such as 
one for Database, another one for LDAP, even one more in tomcat-usrs.xml 
format. Examples:





 

  

  

  

 

 

 

 

 





The certificate of this web-app will be included in the context if it has 
one.

When the web-app is running, it might have to access its own certificate, 
too.



[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38329] - isapi_redirect.dll returns application not available when application stopped in Manager

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38329


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 10:34 ---
This is the exact purpose of 'stopped'.
You can use 'disabled' to deal with existing sessions.

The stopped means: No more requests to this route!

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: UserManager should be added

[Terry Zhou]

Tomcat does have a realm in different level(Engine,Host,Webapp) for
security.
Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html


2006/1/20, Jack <[EMAIL PROTECTED]>:
>
>
> In order to add a new user to a web-app, since specification 2.4 doesn't
> cover this, web-app might have to take care of this. User information will
> be used by web-app anyway, the web-app keeps many information about the
> user. Keep its password is not difficult at all, and it is easier for the
> web-app to change password for the user. In case the user uses a
> certificate, the web-app might also use the certificate anyway. So the
> UserManager will be used by both the web-app Container & the web-app.
>
>
>
> There are 3 types user contexts:
>
> 1. Engine user context (tomcat-userx.xml, should not mix up with host &
> web-app user context. At present, they all mixed up.)
>
> 2. Host user context (Users defined in a host user context will be
> available
> to all web-apps in this host.)
>
> 3. Web-app user context
>
>
>
> Under the Engine element, add a Users element (EngineUserContext). Its
> content is the content of tomcat-users.xml, and tomcat-users.xml could be
> eliminate, or an attribute in Users link to tomcat-users.xml.
>
> Under each Host element, there could be a Users element (HostUserContext),
> too.
>
> In the context.xml for each web-app, there could be a Users element
> (WebAppUserContext), too.
>
>
>
> In Host Users & web-app users elements, the possible attributes are:
>
>
>
> scope=host|engine whether users information available to other context.
> "host" is the default value.
>
> useHost=yes|noUsing users defined in the host context. default: yes
>
> useOtherWebApp=yes|no   Using users defined in other web-app exposed to
> the
> same host. default: yes
>
> useOtherHost=yes|noUsing users defined in other host exposed to the
> same
> engine. default: no
>
> clientAuth
>
> keystoreFile
>
> keystorePass
>
> keystoreType
>
> truststoreFile
>
> truststorePass
>
> truststoreType
>
>
>
> The last 6 attributes of Connector element should become attributes of
> Users
> elements since they are all UserContext properties.
>
>
>
> "clientAuth" is configed in the login-config element in web.xml. If the
> client is requesting a server resource that requires client
> authentication,
> the server requests the client's certificate. However, it could also be
> put
> on Users element.
>
>
>
> Single Signon
>
> At present, single signon is done with a valve.
>
>
>
> For a user crosses a web-app (1) to another web-app (2) to access a
> constrained resource, the authorizer(Realm) will call the UserManager
> whether the user has a role for the resource. And the UserManager will
> consult the user context of the web-app 2 to check whether it accept users
> from web-app 1. If yes, and the user is authenticated, then the container
> doesn't have to ask the user do authentication again.
>
>
>
> This will be more logic than the original implementation with valve.
>
>
> [EMAIL PROTECTED]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--


Terry(Xiaochao) Zhou

The original Realm

[Jack]

"Terry Zhou" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>Tomcat does have a realm in different level(Engine,Host,Webapp) for 
>security.
>Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html
Personally, I believe that the original Realm mixed up the authentication & 
authorization.
It should be seperated into Authorizer & UserRealm.

The reason why I suggest to add user package is that the source code of the 
original implementation is not easy to be integrated into the source code of 
web-app.

Principal is web-app dependant



HttpServletRequest.getRemoreUser() returns the name of the user of the 
request. When we use certificates, the return object is not well defined 
since there is no name here.

HttpServletRequest.getUserPrincipal() doesn't have a good definition, 
either. It just says the principal name of the current authenticated user. 
So, what is in the returned Principal object is up to the container, too. 
However, the reason to have such a method is to let the web-app can access 
it. And so, the returned Principal should be web-app dependent. We had 
better to ask the web-app to implement the Principal if the web-app care who 
the user is. In such a case, we had better leave the authentication to the 
web-app (in UserContext), too.



If the web-app doesn't care at all, then we can use GenericPrincipal as the 
current implementation.


[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

UserManager managing UserContexts

[Jack]

"Terry Zhou" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>Tomcat does have a realm in different level(Engine,Host,Webapp) for 
>security.
>Check http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html

The document really says that, but as I tried, the result is disappointing. 
It just doesn't work.
I guess the document might just give the direction to go. If it works for 
you please let me know.

I added this into context.xml:

 

Furthermore, I want to have a UserContext component. The users' information 
might be store in several places.
Any classes just have to deal with UserContext, all details will be 
encapsulated inside the UserContext such as access keystore, truststore, or 
database, ldap.

And single signon will become more logic, easier to controle.

[EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=35853





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 11:56 ---
Hi Mladen Turk,

Thanks for that but I find it doesn't work for me when using Tomcat 5.5.12,
Mod_jk 1.2.15, Apache 2.0.54.

using JkMount /jsp-examples works, using JkMount /JSPWiki doesn't. Renaming
JSPWiki to jspwiki and using JkMount /jspwiki works.



-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Response not flushed before RD.forward() returns

[Remy Maucherat]

Jan Luehe wrote:


Bill Barker wrote On 01/19/06 18:11,:
 




-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 19, 2006 5:57 PM

To: tomcat-dev@jakarta.apache.org
Subject: Response not flushed before RD.forward() returns

Consider the following code snippet of a servlet's service() method:

 public class DispatcherServlet extends HttpServlet {

   public void service(HttpServletRequest req, 
HttpServletResponse res)

   throws IOException, ServletException {

 
request.getRequestDispatcher("/target").forward(request, response);


 try {
 Thread.currentThread().sleep(6);
 } catch (Exception ex) { }
   }

where "target" prints some output to the response.

The code currently returns the output printed by "target" only after
DispatcherServlet's service() method has finished, instead of right
before RD.forward() returns.

This seems to be in violation of the Servlet Spec, which has this:

SRV.8.4 ("The Forward Method"):

 Before the forward() method of the RequestDispatcher interface
 returns, the response content must be sent and committed, and closed
 by the servlet container.

The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
looks like this:

   // This is not a real close in order to support error 
processing

   if ( log.isDebugEnabled() )
   log.debug(" Disabling the response for futher output");

   if  (response instanceof ResponseFacade) {
   ((ResponseFacade) response).finish();
   } else {
   // Servlet SRV.6.2.2. The Resquest/Response may have been
wrapped
   // and may no longer be instance of RequestFacade
   if (log.isDebugEnabled()){
   log.debug( " The Response is vehiculed using 
a wrapper: "

  + response.getClass().getName() );
   }

   // Close anyway
   try {
   PrintWriter writer = response.getWriter();
   writer.close();
   } catch (IllegalStateException e) {
   try {
   ServletOutputStream stream = 
response.getOutputStream();

   stream.close();
   } catch (IllegalStateException f) {
   ;
   } catch (IOException f) {
   ;
   }
   } catch (IOException e) {
   ;
   }
   }

In the above code sample, response will be an instance of
ResponseFacade, meaning it will be suspended instead of being flushed
and closed right away.

Does anyone remember why the "response instanceof ResponseFacade"
check is there? I would have expected the "else" case to always be
executed.



Without ever actually having looked at ResponseFacade, I'd always assumed
that ResponseFacade.finish called Response.finishResponse.  And I would have
been wrong ;-).  This would have done the commit/send/close properly.

I don't have time right now to dig through the SVN logs to see why it's this
way, but suspended doesn't really look good enough to satisfy the spec.


Yes. I'm afraid it's been like this forever.


And it has to stay like this forever too: this needs to get some post 
processing done (like error pages, etc). If this person wants to flush, 
let him call flush.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=35853





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 12:32 ---
Right.

The problem is that mod_jk needs to follow the common
denominator of the web server, not servlet-api.
Many OS-es does not allow case sensitivity, so the lowrecase
is that common denomitator.
It is something that you'll have to live with :)


-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Response not flushed before RD.forward() returns

[Remy Maucherat]

Bill Barker wrote:

Without ever actually having looked at ResponseFacade, I'd always assumed
that ResponseFacade.finish called Response.finishResponse.  And I would have
been wrong ;-).  This would have done the commit/send/close properly.


It has always been like this: processing for error pages and status 
report pages has to occur later. It's the same for other similarly 
worded mechanisms, such as sendError, sendRedirect, etc.



I don't have time right now to dig through the SVN logs to see why it's this
way, but suspended doesn't really look good enough to satisfy the spec.


It is the best and only acceptable behavior from a usability standpoint, 
however.


There are other areas where I think implementing the letter of the 
specification turned out completely wrong, such as the charset handling 
that Jan implemented some time before (aka, forcing the addition of a 
charset even if none was specified whenever a writer is being used).


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38332] New: - Documented AJP Connector configuration for pending request queue size in error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38332

   Summary: Documented AJP Connector configuration for pending
request queue size in error
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
   URL: http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


In configuring my AJP13 connector between Tomcat 5.5.9 and Apache2 (on Red Hat 
Enterprise 3 with Java 1.5) I am finding that the attribute named "backlog" 
seems to have no affect, while the attribute named "acceptCount" does.

In my original load/configuration testing for deployment I had copied existing 
Connector configuration in the server.xml file from other defined Connectors.  
These use the "acceptCount" attribute name to manipulate the size of the 
pending request queue size.  However, the documentation for this same 
configuation specifies the use of "backlog", which does not appear to have an 
effect on performance.

I have inquired the users group about this topic, but have had no reply.  
Since I am seeing a performance change using "acceptCount", I can only assume 
at this time that the documentation is in error.

See http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

problem with lost request parameters

[Jair da Silva Ferreira Jr]

Hi,
   I posted this email in tomcat users list, but no one there could 
really help me. So, I decided to post it here in the developers list 
because I think there is a problem with tomcat code and maybe a 
developer would help me better. I am sorry if I am incovenient in any way.


   Here is my problem:
   I have my web application hosted at brazilian Locaweb. It runs on a
Linux as40-32bits server with tomcat 5.5.15 and java 5. My application
runs with many (I don't know exactly how many) others in the same tomcat
server. My application uses postgresql 8 database, hibernate 2.1.7c,
servlet 2.4, jsp 2.0, jstl 1.1 and tiles without struts.

   My problem is that I can't get the request parameters submitted by
some of my users. My form uses the post method to submit its data. When
I call request.getParameter("validationScheme") in my servlet I get
null. request.getParametersNames() also returns an empty Enumeration. My
servlet then throws a ServletException because it can't find a mandatory
parameter. I have never experienced this problem in forms that use the
"get" method to submit its data. My form has few parameters, they are:
validationScheme (hidden), email and password. It is a simple login
form. Here is the relevant html code for my form:

" method="post" style="margin:0"
enctype="application/x-www-form-urlencoded" accept-charset="ISO-8859-1">
   
   
   e-mail
   
   
   
   senha
   
   
   
   
   
   

   I have already tried the following:
  - adding <%@ page contentType="text/html; charset=ISO-8859-1" %>
declaration in all my jsp pages;
  - adding   attributes in all my html forms;
  - adding  in all my jsp and html pages;
  - adding a filter that sets the request character encoding to
ISO-8859-1 (request.setCharacterEncoding("ISO-8859-1")). This filter is
executed for every jsp and servlet in my application;
  - searched the web for "tomcat lost request parameter" and
"tomcat lose request parameter" using google and found nothing that
could help me;

   I asked the support people from Locaweb to execute tcpdump while my
user tried to submit the form. tcpdump results showed that the request
parameters are getting to tomcat correctly. So, I think that tomcat is
losing these parameters for some reason that I don't understand.

   I also noticed that these errors don't happen to all of my users,
but when it happens to a specific user, it can be easily reproduced by
that user. Unfortunately, I have never been able to reproduce the error
in my machines.

   Here is some user information logged by my error page when the
problem happens:
===
user 1
===
Thu Jan 19 11:45:05 BRST 2006
Request that failed: /v.servlet
Status code: 500
Protocol: HTTP/1.0
Remote Address: 201.9.198.113
Remote Host: 201.9.198.113
Remote Port: 0
Local Address:
Local Name: www.dvdfilme.com.br
Local Port: 80
Server Name: www.dvdfilme.com.br
Server Port: 80
User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
FunWebProducts)
Request Character Encoding: ISO-8859-1
Request Content-type: application/x-www-form-urlencoded
Response Character Encoding: ISO-8859-1
Response Content-type: text/html
Request Locale: pt_BR
Response Locale: pt_BR
Throwable: javax.servlet.ServletException: 'validationScheme' request
parameter not found
 (exception stack trace)
request parameters: {}

===
user 2
===
Thu Jan 19 12:13:37 BRST 2006
Request that failed: /v.servlet
Status code: 500
Protocol: HTTP/1.1
Remote Address: 201.29.118.23
Remote Host: 201.29.118.23
Remote Port: 0
Local Address:
Local Name: www.dvdfilme.com.br
Local Port: 80
Server Name: www.dvdfilme.com.br
Server Port: 80
User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Request Character Encoding: ISO-8859-1
Request Content-type: application/x-www-form-urlencoded
Response Character Encoding: ISO-8859-1
Response Content-type: text/html
Request Locale: pt_BR
Response Locale: pt_BR
Throwable: javax.servlet.ServletException: 'validationScheme' request
parameter not found
 (exception stack trace)
request parameters: {}

   I also looked at tomcat 5.5.15 source code, class
org.apache.coyote.tomcat4.CoyoteRequest, method parseRequestParameters()
and noticed that expections (Throwable) are "swallowed" in request
parameter processing. So, I think that if any problem happens during
this process, the code will silently ignore the request parameter. I
also think that this is what is happening in my case. Here is the
relevant part of the code:

   /**
* Parse request parameters.
*/
   protected void parseRequestParameters() {
   
   int len = getContentLength();

   if (len > 0) {
   try {
   byte[] formData = null;
   if (len < CACHED_POST_LEN) {
   if (postData == null)
   postData = new byte[CACHED_POST_LEN];
   formData = postData;
   } else {
   formData = ne

DO NOT REPLY [Bug 37859] - add a reliable "real_remote_socket" and "real_remote_port" attribute to requets

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37859


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|major   |enhancement
 Status|RESOLVED|REOPENED
 Resolution|INVALID |
Summary|getServerPort() not reliable|add a reliable
   ||"real_remote_socket" and
   ||"real_remote_port" attribute
   ||to requets
Version|5.5.9   |Unknown




--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 19:00 ---
ok, understood - especially if there is a proxy in-between you don't want the
proxy address but the address and port of the original requestor.

However, wouldn't it be useful, to add e.g. in
org.apache.coyote.http11.Http11Processor

a request.setAttribute("javax.servlet.request.real_remote_host", socket.
getRemoteSocketAddress()); //or socket.getInetAddress() ?
and a request.setAttribute("javax.servlet.request.real_remote_port",
socket.getPort())
?

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Security Manager

[George Sexton]

I tried running 5.5.14 with -security specified and got this error:

Using Security Manager
Listening for transport dt_socket at address: 7100
Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
java.security.AccessControlException: access denied
(java.lang.RuntimePermission
 shutdownHooks)
at
java.security.AccessControlContext.checkPermission(AccessControlConte
xt.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:
427)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)


My solution was to add:

grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
permission java.security.AllPermission;
};

To the catalina.policy file. Is this correct?

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37859] - add a reliable "real_remote_socket" and "real_remote_port" attribute to requets

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37859





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 19:21 ---
In the case of proxies - that is what proxyName and proxyPort are for:
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Security Manager

[George Sexton]

It also seems to me the policy file should have:

grant codeBase "file:${catalina.base}/shared/-" {
permission java.security.AllPermission;
};

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

> -Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED] 
> Sent: Friday, January 20, 2006 11:14 AM
> To: 'Tomcat Developers List'
> Subject: Security Manager
> 
> I tried running 5.5.14 with -security specified and got this error:
> 
> Using Security Manager
> Listening for transport dt_socket at address: 7100
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
>  shutdownHooks)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> 
> 
> My solution was to add:
> 
> grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
> permission java.security.AllPermission;
> };
> 
> To the catalina.policy file. Is this correct?
> 
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>  
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Security Manager

[George Sexton]

It also seems to me the policy file should have:

grant codeBase "file:${catalina.base}/shared/-" {
permission java.security.AllPermission;
};

And 

permission java.util.PropertyPermission "java.io.tmpdir", "read";

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

> -Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED] 
> Sent: Friday, January 20, 2006 11:14 AM
> To: 'Tomcat Developers List'
> Subject: Security Manager
> 
> I tried running 5.5.14 with -security specified and got this error:
> 
> Using Security Manager
> Listening for transport dt_socket at address: 7100
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
>  shutdownHooks)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> 
> 
> My solution was to add:
> 
> grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
> permission java.security.AllPermission;
> };
> 
> To the catalina.policy file. Is this correct?
> 
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>  
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Security Manager

[George Sexton]

Yet more. It seems by specification (SRV.3.7.1)

grant {
  permission java.io.FilePermission "${catalina.base}/temp/-", "read,
write","delete";
  permission java.util.PropertyPermission "javax.servlet.context.tempdir",
"read"; 
};

Really should be set so.

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

> -Original Message-
> From: George Sexton [mailto:[EMAIL PROTECTED] 
> Sent: Friday, January 20, 2006 11:14 AM
> To: 'Tomcat Developers List'
> Subject: Security Manager
> 
> I tried running 5.5.14 with -security specified and got this error:
> 
> Using Security Manager
> Listening for transport dt_socket at address: 7100
> Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission
>  shutdownHooks)
> at
> java.security.AccessControlContext.checkPermission(AccessControlConte
> xt.java:264)
> at
> java.security.AccessController.checkPermission(AccessController.java:
> 427)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> 
> 
> My solution was to add:
> 
> grant codeBase "file:${catalina.home}/bin/tomcat-juli.jar" {
> permission java.security.AllPermission;
> };
> 
> To the catalina.policy file. Is this correct?
> 
> George Sexton
> MH Software, Inc.
> http://www.mhsoftware.com/
> Voice: 303 438 9585
>  
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38335] New: - Tomcat fails to shut down in response to shutdown.sh script

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38335

   Summary: Tomcat fails to shut down in response to shutdown.sh
script
   Product: Tomcat 5
   Version: 5.5.12
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:Coyote
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Tomcat fails to shut down in response to shutdown.sh script.  Hangs,
eventually throws exception with dreaded "Protocol handler pause failed"
message.  I have tried both values for LD_ASSUME_KERNEL as per release
notes.  It changes the behavior slightly, but the problem remains (more
below).

Environment:

- A freshly built & updated fedora RC4 install: 2.6.14-1.1656_FC4

- A completely unmodified Tomcat Version 5.5.12 - I untarred it and ran it.

- Sun's jdk1.5.0_06

Repro:

1) run startup.sh
2) hit localhost:8080 in browser, works
3) run shutdown.sh
4) log shows:

Jan 19, 2006 11:08:27 PM org.apache.coyote.http11.Http11BaseProtocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080

It hangs for a minute or so, then throws:

Jan 19, 2006 11:03:48 PM org.apache.catalina.connector.Connector pause
SEVERE: Protocol handler pause failed
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:507)
at java.net.Socket.connect(Socket.java:457)
at java.net.Socket.(Socket.java:365)
at java.net.Socket.(Socket.java:207)
at 
org.apache.jk.common.ChannelSocket.unLockSocket(ChannelSocket.java:463)
at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:270)
at org.apache.jk.server.JkMain.pause(JkMain.java:679)
at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:162)
at org.apache.catalina.connector.Connector.pause(Connector.java:1031)
at 
org.apache.catalina.core.StandardService.stop(StandardService.java:491)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:714)
   at org.apache.catalina.startup.Catalina.stop(Catalina.java:586)
at org.apache.catalina.startup.Catalina.start(Catalina.java:561)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Interestingly enough, lsof shows different behaviors depending on the
value of the LD_ASSSUME_KERNEL variable.  With no variable set, 

# lsof -P | grep java | grep 8080
java  6555   chris   10u IPv6 329120  TCP *:8080
(LISTEN)

setting LD_ASSUME_KERNEL=2.2.5 results in about 40 threads listening on
the port (in the hung state):

# lsof -P | grep java | grep 8080
java  6652   chris   12u IPv6 331547  TCP *:8080
(LISTEN)
java  6653   chris   12u IPv6 331547  TCP *:8080
(LISTEN)
...etc

setting it to 2.4.1 yields the more entertaining:

# lsof -P | grep java | grep 8080
java  6779   chris  mem   REG  253,0   14656364980808
/lib/obsolete/linuxthreads/i686/libc-2.3.5.so
java  6779   chris   12u IPv6 334251  TCP *:8080
(LISTEN)
java  6780   chris  mem   REG  253,0   14656364980808
/lib/obsolete/linuxthreads/i686/libc-2.3.5.so
java  6780   chris   12u IPv6 334251  TCP *:8080
(LISTEN)
...

but the behavior is the same.  Surely tomcat on Fedora can't be this broken out
of the box, can it?

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37859] - add a reliable "real_remote_socket" and "real_remote_port" attribute to requets

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37859


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 23:02 ---
(In reply to comment #2)
> ok, understood - especially if there is a proxy in-between you don't want the
> proxy address but the address and port of the original requestor.
> However, wouldn't it be useful, to add e.g. in
> org.apache.coyote.http11.Http11Processor
> a request.setAttribute("javax.servlet.request.real_remote_host", socket.
> getRemoteSocketAddress()); //or socket.getInetAddress() ?
> and a request.setAttribute("javax.servlet.request.real_remote_port",
> socket.getPort())
> ?

Seems pretty useless, since it simply duplicates what is already available via 
request.getRemoteAddr() and request.getRemotePort().




-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38337] New: - GlobalNamingResource will not allow commercial DataSource drivers

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38337

   Summary: GlobalNamingResource will not allow commercial
DataSource drivers
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: Windows Server 2003
Status: NEW
  Severity: critical
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


We have the same datasource configurations for three webapps that we host on the
same server.  We want to merge those configurations into one place with
GlobalNamingResource.  The exact same configuration in the  element
will not work with the  element.

Here is an example Resource config:

   
   

When that configuration lives inside a  element everything works as
expected.  When it lives inside a  Tomcat tries to use the
DBCP driver with the exception thrown:

org.apache.tomcat.dbcp.dbcp.SQLNestedException: Canot create JDBC driver of
class '' for connect URL 'null'
  stack trace omitted 

We do not want to use DBCP, we want to use the JNetDirect pooling drivers we
paid for.  Why is this happening?

We are using Tomcat 5.5.12 (sorry there was no entry for it here) on Windows. 
This seriously affects our deployment model as we will need to use the same
connections for server authentication in the very near future.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 21:37 ---
I'm happy to look at adding CLIENT-CERT support to the JNDI realm based on your
proposal. If I put together a patch are you willing to test it? If yes, I can
use 5.5.x or 4.1.x. Which would you prefer?

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38335] - Tomcat fails to shut down in response to shutdown.sh script

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=38335





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 21:52 ---
NOT reproducible using same JDK and tomcat versions on Fedora 3 install.

same java:
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)

same tomcat: Apache Tomcat/5.5.12

different kernel:
Linux 2.6.12-1.1381_FC3

different glibc.  this box works:

$ rpm -qa | grep -i libc
libcap-1.10-20
glibc-2.3.5-0.fc3.1
glibc-devel-2.3.5-0.fc3.1
libcap-devel-1.10-20
glibc-kernheaders-2.4-9.1.87
glibc-common-2.3.5-0.fc3.1
glibc-headers-2.3.5-0.fc3.1

this box doesn't work:

$ rpm -qa | grep -i libc
glibc-common-2.3.5-10.3
libcroco-0.6.0-5
libcap-devel-1.10-22
libcroco-devel-0.6.0-5
glibc-2.3.5-10.3
glibc-devel-2.3.5-10.3
glibc-kernheaders-2.4-9.1.94
glibc-2.3.5-10
libcap-1.10-22
glibc-headers-2.3.5-10.3


-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Re: Response not flushed before RD.forward() returns]

[Jan Luehe]

Remy Maucherat wrote On 01/20/06 03:45,:
> I tried to post that to dev, but there's apparently some issue since my 
> message hasn't been posted yet.
> 
> Rémy
> 
>  Original Message 
> Subject: Re: Response not flushed before RD.forward() returns
> Date: Fri, 20 Jan 2006 12:08:30 +0100
> From: Remy Maucherat <[EMAIL PROTECTED]>
> To: Tomcat Developers List 
> References: <[EMAIL PROTECTED]> 
> <[EMAIL PROTECTED]>
> 
> Jan Luehe wrote:
> 
>>Bill Barker wrote On 01/19/06 18:11,:
>>
>>> 
>>>
>>>
>>>
-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 19, 2006 5:57 PM
To: tomcat-dev@jakarta.apache.org
Subject: Response not flushed before RD.forward() returns

Consider the following code snippet of a servlet's service() method:

 public class DispatcherServlet extends HttpServlet {

   public void service(HttpServletRequest req, 
HttpServletResponse res)
   throws IOException, ServletException {

 
request.getRequestDispatcher("/target").forward(request, response);

 try {
 Thread.currentThread().sleep(6);
 } catch (Exception ex) { }
   }

where "target" prints some output to the response.

The code currently returns the output printed by "target" only after
DispatcherServlet's service() method has finished, instead of right
before RD.forward() returns.

This seems to be in violation of the Servlet Spec, which has this:

SRV.8.4 ("The Forward Method"):

 Before the forward() method of the RequestDispatcher interface
 returns, the response content must be sent and committed, and closed
 by the servlet container.

The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
looks like this:

   // This is not a real close in order to support error 
processing
   if ( log.isDebugEnabled() )
   log.debug(" Disabling the response for futher output");

   if  (response instanceof ResponseFacade) {
   ((ResponseFacade) response).finish();
   } else {
   // Servlet SRV.6.2.2. The Resquest/Response may have been
wrapped
   // and may no longer be instance of RequestFacade
   if (log.isDebugEnabled()){
   log.debug( " The Response is vehiculed using 
a wrapper: "
  + response.getClass().getName() );
   }

   // Close anyway
   try {
   PrintWriter writer = response.getWriter();
   writer.close();
   } catch (IllegalStateException e) {
   try {
   ServletOutputStream stream = 
response.getOutputStream();
   stream.close();
   } catch (IllegalStateException f) {
   ;
   } catch (IOException f) {
   ;
   }
   } catch (IOException e) {
   ;
   }
   }

In the above code sample, response will be an instance of
ResponseFacade, meaning it will be suspended instead of being flushed
and closed right away.

Does anyone remember why the "response instanceof ResponseFacade"
check is there? I would have expected the "else" case to always be
executed.

>>>
>>>Without ever actually having looked at ResponseFacade, I'd always assumed
>>>that ResponseFacade.finish called Response.finishResponse.  And I would have
>>>been wrong ;-).  This would have done the commit/send/close properly.
>>>
>>>I don't have time right now to dig through the SVN logs to see why it's this
>>>way, but suspended doesn't really look good enough to satisfy the spec.
>>
>>Yes. I'm afraid it's been like this forever.
> 
> 
> And it has to stay like this forever too: this needs to get some post
> processing done (like error pages, etc). If this person wants to flush,
> let him call flush.

Right, but flush does nothing once the response has been suspended.

In addition, consider the case where a request has been
forward-dispatched into a foreign context. If the target
servlet in the foreign context has set a status code on the response,
and the response is being suspended before returning from the
RD.forward(), the status code will be mapped to an error page
using the mappings of the *origin* context as the response
travels through the origin context's pipeline (and error valve)
on the way out.

The origin and target contexts may map the same status code to
different error pages, or the origin context may not even contain any
mapping for the given status code. In any case, I would find it
confusing for the origin context's mappings to be used, since
a RD.forward() is supposed to transfer control to the target.

I think it is cleaner for the response to be commi

Please give me some responses!!

[Jack]

Hi,

guys, please give me some responses!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r370985 - in /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator: BasicAuthenticator.java DigestAuthenticator.java

[billbarker]

Author: billbarker
Date: Fri Jan 20 21:21:15 2006
New Revision: 370985

URL: http://svn.apache.org/viewcvs?rev=370985&view=rev
Log:
Use sendError instead of setStatus to send the 401 code.

This is per section 9.9.2 of the spec.  It doesn't seem to cause any problems 
in my testing, and it also allows (the mostly useless) custom 401 page.


Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java?rev=370985&r1=370984&r2=370985&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java
 Fri Jan 20 21:21:15 2006
@@ -201,7 +201,7 @@
 }
 authenticateCC.append('\"');
 authenticate.toChars();
-response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
+response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
 //response.flushBuffer();
 return (false);
 

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java?rev=370985&r1=370984&r2=370985&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java
 Fri Jan 20 21:21:15 2006
@@ -189,7 +189,7 @@
 String nOnce = generateNOnce(request);
 
 setAuthenticateHeader(request, response, config, nOnce);
-response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
+response.sendError(HttpServletResponse.SC_UNAUTHORIZED);
 //  hres.flushBuffer();
 return (false);
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fwd: Help :: Running Servlet Prog. in Apache HTTP Server -reg

[Ghanesh MV]

Hi Everybody,

Plz Help me

How to use Servlets with Apache

I found there is an additional module named mod_jk for Apache to do the
interaction between the Apache HTTP Webserver and the Tomcat's Catalina
Container.

I can't find info about the usage of mod_jk and conf details

Plz help me as soon as possible.

I'm inneed of it very urgently to continue with my academic project

Thank u Everybody for considering this mail

Regret my mistake if any

Awaiting for the reply eagerly

Thank u

Urs..

GhaneshMV

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7831





--- Additional Comments From [EMAIL PROTECTED]  2006-01-21 07:50 ---
Cool, Thanks!

For sure I will test it.

I prefer 5.5.x

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Re: Response not flushed before RD.forward() returns]

[Remy Maucherat]

Jan Luehe wrote:

Right, but flush does nothing once the response has been suspended.

In addition, consider the case where a request has been
forward-dispatched into a foreign context. If the target
servlet in the foreign context has set a status code on the response,
and the response is being suspended before returning from the
RD.forward(), the status code will be mapped to an error page
using the mappings of the *origin* context as the response
travels through the origin context's pipeline (and error valve)
on the way out.

The origin and target contexts may map the same status code to
different error pages, or the origin context may not even contain any
mapping for the given status code. In any case, I would find it
confusing for the origin context's mappings to be used, since
a RD.forward() is supposed to transfer control to the target.

I think it is cleaner for the response to be committed before
returning from RD.forward(), at the cost of not being mapped
to any error page. This is better than mapping the response to
a wrong error page. Or we could suspend the response when the
origin and target servlets share the same context, and commit it
when they reside in different contexts? Clearly, this would require
a spec clarification.


-1

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]