You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by lu...@apache.org on 2003/06/05 18:42:48 UTC

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

luehe       2003/06/05 09:42:48

  Modified:    coyote/src/java/org/apache/coyote Request.java
               http11/src/java/org/apache/coyote/http11
                        Http11Processor.java Http11Protocol.java
  Log:
  Removed setSocket() method from org.apache.catalina.Request, since it
  was never called in any of the classes implementing this interface.
  
  For example, setSocket() was never called on
  org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
  method to always return null, which broke the CertificatesValve, which
  relies on having access to the (SSL)Socket so that it can reinitiate a
  handshake if necessary.
  
  Instead, added setSocket() and getSocket() methods on org.apache.coyote.Request:
  
  - setSocket() is called as part of
    org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
  
      public void setSocket(Socket socket)
          throws IOException {
          this.socket = socket;
          this.request.setSocket(socket); // NEW
      }
  
  - getSocket() is called as part of
    org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
  
  diff -u -r1.5 CoyoteRequest.java
  --- CoyoteRequest.java  31 May 2003 15:00:25 -0000      1.5
  +++ CoyoteRequest.java  5 Jun 2003 16:41:17 -0000
  @@ -633,20 +633,7 @@
        * an SSLSocket.
        */
       public Socket getSocket() {
  -        return (socket);
  -    }
  -
  -    /**
  -     * Set the Socket (if any) through which this Request was received.
  -     *
  -     * @param socket The socket through which this request was received
  -     */
  -    public void setSocket(Socket socket) {
  -        this.socket = socket;
  -        remoteHost = null;
  -        remoteAddr = null;
  -        remotePort = -1;
  -        localAddr = null;
  +        return coyoteRequest.getSocket();
       }
  
  Revision  Changes    Path
  1.21      +20 -0     jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
  
  Index: Request.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- Request.java	23 Mar 2003 08:57:48 -0000	1.20
  +++ Request.java	5 Jun 2003 16:42:48 -0000	1.21
  @@ -62,6 +62,7 @@
   
   import java.io.IOException;
   import java.util.Hashtable;
  +import java.net.Socket;
   
   import org.apache.tomcat.util.buf.ByteChunk;
   import org.apache.tomcat.util.buf.MessageBytes;
  @@ -137,6 +138,8 @@
       
       private int remotePort;
   
  +    private Socket socket;
  +
       private MessageBytes schemeMB = new MessageBytes();
   
       private MessageBytes methodMB = new MessageBytes();
  @@ -304,6 +307,23 @@
           this.remotePort = port;
       }
   
  +    /**
  +     * Sets the socket through which this request was received.
  +     *
  +     * @param socket The socket through which this request was received
  +     */
  +    public void setSocket(Socket socket) {
  +	this.socket = socket;
  +    }
  +
  +    /**
  +     * Gets the socket through which this request was received.
  +     *
  +     * @return The socket through which this request was received
  +     */
  +    public Socket getSocket() {
  +	return socket;
  +    }
   
       // -------------------- encoding/type --------------------
   
  
  
  
  1.66      +1 -0      jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- Http11Processor.java	13 May 2003 22:45:58 -0000	1.65
  +++ Http11Processor.java	5 Jun 2003 16:42:48 -0000	1.66
  @@ -517,6 +517,7 @@
       public void setSocket(Socket socket)
           throws IOException {
           this.socket = socket;
  +	this.request.setSocket(socket);
       }
   
       /**
  
  
  
  1.27      +6 -5      jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
  
  Index: Http11Protocol.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- Http11Protocol.java	22 May 2003 04:51:03 -0000	1.26
  +++ Http11Protocol.java	5 Jun 2003 16:42:48 -0000	1.27
  @@ -86,8 +86,8 @@
    */
   public class Http11Protocol implements ProtocolHandler, MBeanRegistration
   {
  -
       public Http11Protocol() {
  +	cHandler = new Http11ConnectionHandler( this );
           setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
           setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
           setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
  @@ -99,9 +99,6 @@
       protected static StringManager sm =
           StringManager.getManager(Constants.Package);
   
  -    Adapter adapter;
  -    Http11ConnectionHandler cHandler=new Http11ConnectionHandler( this );
  -
       /** Pass config info
        */
       public void setAttribute( String name, Object value ) {
  @@ -220,6 +217,9 @@
       private String reportedname;
       private int socketCloseDelay=-1;
       private boolean disableUploadTimeout = true;
  +    private Adapter adapter;
  +    private Http11ConnectionHandler cHandler;
  +
       /**
        * Compression value.
        */
  @@ -442,7 +442,8 @@
               return  thData;
           }
   
  -        public void processConnection(TcpConnection connection, Object thData[]) {
  +        public void processConnection(TcpConnection connection,
  +				      Object thData[]) {
               Socket socket=null;
               Http11Processor  processor=null;
               try {
  
  
  

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


Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

Posted by Jan Luehe <Ja...@Sun.COM>.
Remy,

> > P.S.: I'm also +1 for removing the CertificatesValve, since it is
> > confusing to have several valves essentially doing the same thing.
> 
> There's no need to hardcode the authenticator, you only need to add it
> in startup.Authenticators.properties, and it will be added in the
> pipeline as needed. It's already there, BTW, so I don't quite see what's
> going on (but it should be fixed there, no harcoding required).

yes, I understand. The confusing part was that in ContextConfig, we
were adding both the CertificatesValve (in certificatesConfig) and the
Authenticator configured in web-app/login-config/auth-method, where
CertificatesValve and SSLAuthenticator were essentially doing the
same, except that CertificatesValve was operating on the (SSL)Socket
and was always failing on a CoyoteRequest (whose getSocket() always returns
null).

Bill has cleared up this confusion by removing the certificatesConfig() method.

Thanks,


Jan

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


Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Bill,
> 
> 
>>SSLAuthenticator makes a request for a special Request attribute
>>("org.apache.coyote.request.X509Certificate"), which fires off an Action
>>hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
>>
>>I changed TC 5 a little while back to do a lazy-evaluation of the SSL
>>attributes.  If you are seeing problems, that might be where.
> 
> 
> Well, the reason I was still using the (supposedly deprecated)
> CertificatesValve was because it was still being added to the pipeline
> in ContextConfig. I'm going to change ContextConfig as follows:
> 
> Index: ContextConfig.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
> retrieving revision 1.25
> diff -u -r1.25 ContextConfig.java
> --- ContextConfig.java  14 May 2003 17:42:55 -0000      1.25
> +++ ContextConfig.java  5 Jun 2003 23:08:13 -0000
> @@ -497,7 +497,7 @@
>          Valve certificates = null;
>          try {
>              Class clazz =
> -                Class.forName("org.apache.catalina.valves.CertificatesValve");
> +                Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
>              certificates = (Valve) clazz.newInstance();
>          } catch (Throwable t) {
>              return;     // Probably JSSE classes not present
> 
> Even with this fix in place, the SSLAuthenticator's authenticate() method
> was still not being invoked, because org.apache.catalina.authenticator.AuthenticatorBase
> currently does not consider the CLIENT-CERT authentication constraint at
> all.
> 
> After fixing this, the SSL handshake does get renegotiated in the way you
> described, but for some reason the connection then times out. I'm still investigating.
> 
> Thanks for putting me on the right track, Bill!
> 
> Jan
> 
> P.S.: I'm also +1 for removing the CertificatesValve, since it is
> confusing to have several valves essentially doing the same thing.

There's no need to hardcode the authenticator, you only need to add it 
in startup.Authenticators.properties, and it will be added in the 
pipeline as needed. It's already there, BTW, so I don't quite see what's 
going on (but it should be fixed there, no harcoding required).

Remy


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


Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java

Posted by Jan Luehe <Ja...@Sun.COM>.
Bill,

> SSLAuthenticator makes a request for a special Request attribute
> ("org.apache.coyote.request.X509Certificate"), which fires off an Action
> hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
> 
> I changed TC 5 a little while back to do a lazy-evaluation of the SSL
> attributes.  If you are seeing problems, that might be where.

Well, the reason I was still using the (supposedly deprecated)
CertificatesValve was because it was still being added to the pipeline
in ContextConfig. I'm going to change ContextConfig as follows:

Index: ContextConfig.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.25
diff -u -r1.25 ContextConfig.java
--- ContextConfig.java  14 May 2003 17:42:55 -0000      1.25
+++ ContextConfig.java  5 Jun 2003 23:08:13 -0000
@@ -497,7 +497,7 @@
         Valve certificates = null;
         try {
             Class clazz =
-                Class.forName("org.apache.catalina.valves.CertificatesValve");
+                Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
             certificates = (Valve) clazz.newInstance();
         } catch (Throwable t) {
             return;     // Probably JSSE classes not present

Even with this fix in place, the SSLAuthenticator's authenticate() method
was still not being invoked, because org.apache.catalina.authenticator.AuthenticatorBase
currently does not consider the CLIENT-CERT authentication constraint at
all.

After fixing this, the SSL handshake does get renegotiated in the way you
described, but for some reason the connection then times out. I'm still investigating.

Thanks for putting me on the right track, Bill!

Jan

P.S.: I'm also +1 for removing the CertificatesValve, since it is
confusing to have several valves essentially doing the same thing.

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


Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java

Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jan Luehe" <Ja...@Sun.COM>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 05, 2003 12:05 PM
Subject: Re: cvs
commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Htt
p11Processor.java Http11Protocol.java


> Remy/Bill,
>
> > Ouch, that's one nasty hack.
> > -1, please revert it.
> >
> > There are callbacks to the processor to evaluate the SSL related
> > attributes. If something is broken, this should be fixed, but using that
> > pattern. I believe get/setSocket are useless, and the calls should be
> > entierely removed.
>
> I noticed the ActionHook calls to get SSL related attributes, however,
> CertificatesValve needs the SSLSocket in order to renegotiate an SSL
> handshake if the requested resource is from a webapp with this
> authentication constraint:
>
>    <login-config>
>       <auth-method>CLIENT-CERT</auth-method>
>    </login-config>
>
> If the request was received through an SSL-enabled connector that does
> not enforce SSL client authentication, the handshake needs to be
> reinitiated, with client authentication enforced. In order to do that,
> CertificatesValve needs access to the SSLSocket, in order to call its
> startHandshake() method.
>
> If the only purpose of CertificatesValve is to support the deprecated
> Http11Connector, which component is going to replace it and implement SSL
> handshake renegotiation?
>

SSLAuthenticator makes a request for a special Request attribute
("org.apache.coyote.request.X509Certificate"), which fires off an Action
hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.

I changed TC 5 a little while back to do a lazy-evaluation of the SSL
attributes.  If you are seeing problems, that might be where.

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


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


Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java

Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Remy/Bill,
> 
> 
>>Ouch, that's one nasty hack.
>>-1, please revert it.
>>
>>There are callbacks to the processor to evaluate the SSL related
>>attributes. If something is broken, this should be fixed, but using that
>>pattern. I believe get/setSocket are useless, and the calls should be
>>entierely removed.
> 
> 
> I noticed the ActionHook calls to get SSL related attributes, however,
> CertificatesValve needs the SSLSocket in order to renegotiate an SSL
> handshake if the requested resource is from a webapp with this
> authentication constraint:
> 
>    <login-config>
>       <auth-method>CLIENT-CERT</auth-method>
>    </login-config>
> 
> If the request was received through an SSL-enabled connector that does
> not enforce SSL client authentication, the handshake needs to be
> reinitiated, with client authentication enforced. In order to do that,
> CertificatesValve needs access to the SSLSocket, in order to call its
> startHandshake() method.
> 
> If the only purpose of CertificatesValve is to support the deprecated
> Http11Connector, which component is going to replace it and implement SSL
> handshake renegotiation?

Well, first of all, even if there's a bug or some missing feature, or 
anything, it's not a valid reason for adding a nasty hack. So please 
revert your patch.

It seems pretty clear to me that if you want to really implement that, 
you could add an additional callback (aka action), like the other SSL 
ones which are already there.
BTW, either there's client cert on the connector, or there isn't, right 
? This seems best left to the lower level of the container, rather than 
trying to be too smart (and since it will be hard to make it consistent 
between JK and HTTP/1.1, I'm close to being -1 for trying to implement 
it). And yes, if JK can't be implemented in a compliant way, then I 
believe that part of the specification is broken and should be fixed.

Remy


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


Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java Http11Protocol.java

Posted by Jan Luehe <Ja...@Sun.COM>.
Remy/Bill,

> Ouch, that's one nasty hack.
> -1, please revert it.
> 
> There are callbacks to the processor to evaluate the SSL related
> attributes. If something is broken, this should be fixed, but using that
> pattern. I believe get/setSocket are useless, and the calls should be
> entierely removed.

I noticed the ActionHook calls to get SSL related attributes, however,
CertificatesValve needs the SSLSocket in order to renegotiate an SSL
handshake if the requested resource is from a webapp with this
authentication constraint:

   <login-config>
      <auth-method>CLIENT-CERT</auth-method>
   </login-config>

If the request was received through an SSL-enabled connector that does
not enforce SSL client authentication, the handshake needs to be
reinitiated, with client authentication enforced. In order to do that,
CertificatesValve needs access to the SSLSocket, in order to call its
startHandshake() method.

If the only purpose of CertificatesValve is to support the deprecated
Http11Connector, which component is going to replace it and implement SSL
handshake renegotiation?


Jan

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


Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

Posted by Remy Maucherat <re...@apache.org>.
luehe@apache.org wrote:
> luehe       2003/06/05 09:42:48
> 
>   Modified:    coyote/src/java/org/apache/coyote Request.java
>                http11/src/java/org/apache/coyote/http11
>                         Http11Processor.java Http11Protocol.java
>   Log:
>   Removed setSocket() method from org.apache.catalina.Request, since it
>   was never called in any of the classes implementing this interface.
>   
>   For example, setSocket() was never called on
>   org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
>   method to always return null, which broke the CertificatesValve, which
>   relies on having access to the (SSL)Socket so that it can reinitiate a
>   handshake if necessary.
>   
>   Instead, added setSocket() and getSocket() methods on org.apache.coyote.Request:
>   
>   - setSocket() is called as part of
>     org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
>   
>       public void setSocket(Socket socket)
>           throws IOException {
>           this.socket = socket;
>           this.request.setSocket(socket); // NEW
>       }
>   
>   - getSocket() is called as part of
>     org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:

Ouch, that's one nasty hack.
-1, please revert it.

There are callbacks to the processor to evaluate the SSL related 
attributes. If something is broken, this should be fixed, but using that 
pattern. I believe get/setSocket are useless, and the calls should be 
entierely removed.

Remy


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


Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 05, 2003 10:54 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java


> Bill Barker wrote:
> > I'm very strongly -1 on this.  The o.a.coyote.Request should not have a
> > set/getSocket method for the simple reason that there is no reason that
> > Coyote should be assumed to be tied to a socket transport.
>
> I plan to test the memory only protocol handler someday. The Netbeans
> folks should be happy about that (and the auto reload everything, of
> course).
>
> > CertificatesValve doesn't do anything any more with Coyote.  It is only
left
> > around to support the deprecated Http11Connector.
>
> Well, the connector won't work with TC 5 anyway, so ...

I'm +1 for removing CertificatesValve from TC 5.  Especially since it is
tied to JSSE 1.0.x, so it will almost certainly break Tomcat running on a
non-Sun 1.4 JVM.

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


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


Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> I'm very strongly -1 on this.  The o.a.coyote.Request should not have a
> set/getSocket method for the simple reason that there is no reason that
> Coyote should be assumed to be tied to a socket transport.

I plan to test the memory only protocol handler someday. The Netbeans 
folks should be happy about that (and the auto reload everything, of 
course).

> CertificatesValve doesn't do anything any more with Coyote.  It is only left
> around to support the deprecated Http11Connector.

Well, the connector won't work with TC 5 anyway, so ...

Remy


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


Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java Http11Protocol.java

Posted by Bill Barker <wb...@wilshire.com>.
I'm very strongly -1 on this.  The o.a.coyote.Request should not have a
set/getSocket method for the simple reason that there is no reason that
Coyote should be assumed to be tied to a socket transport.

CertificatesValve doesn't do anything any more with Coyote.  It is only left
around to support the deprecated Http11Connector.

----- Original Message -----
From: <lu...@apache.org>
To: <ja...@apache.org>
Sent: Thursday, June 05, 2003 9:42 AM
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java Http11Protocol.java


> luehe       2003/06/05 09:42:48
>
>   Modified:    coyote/src/java/org/apache/coyote Request.java
>                http11/src/java/org/apache/coyote/http11
>                         Http11Processor.java Http11Protocol.java
>   Log:
>   Removed setSocket() method from org.apache.catalina.Request, since it
>   was never called in any of the classes implementing this interface.
>
>   For example, setSocket() was never called on
>   org.apache.coyote.tomcat5.CoyoteRequest, causing its getSocket()
>   method to always return null, which broke the CertificatesValve, which
>   relies on having access to the (SSL)Socket so that it can reinitiate a
>   handshake if necessary.
>
>   Instead, added setSocket() and getSocket() methods on
org.apache.coyote.Request:
>
>   - setSocket() is called as part of
>     org.apache.coyote.http11.Http11Processor.setSocket(), as follows:
>
>       public void setSocket(Socket socket)
>           throws IOException {
>           this.socket = socket;
>           this.request.setSocket(socket); // NEW
>       }
>
>   - getSocket() is called as part of
>     org.apache.coyote.tomcat5.CoyoteRequest.getSocket(), as follows:
>
>   diff -u -r1.5 CoyoteRequest.java
>   --- CoyoteRequest.java  31 May 2003 15:00:25 -0000      1.5
>   +++ CoyoteRequest.java  5 Jun 2003 16:41:17 -0000
>   @@ -633,20 +633,7 @@
>         * an SSLSocket.
>         */
>        public Socket getSocket() {
>   -        return (socket);
>   -    }
>   -
>   -    /**
>   -     * Set the Socket (if any) through which this Request was received.
>   -     *
>   -     * @param socket The socket through which this request was received
>   -     */
>   -    public void setSocket(Socket socket) {
>   -        this.socket = socket;
>   -        remoteHost = null;
>   -        remoteAddr = null;
>   -        remotePort = -1;
>   -        localAddr = null;
>   +        return coyoteRequest.getSocket();
>        }
>
>   Revision  Changes    Path
>   1.21      +20 -0
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
>
>   Index: Request.java
>   ===================================================================
>   RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Reques
t.java,v
>   retrieving revision 1.20
>   retrieving revision 1.21
>   diff -u -r1.20 -r1.21
>   --- Request.java 23 Mar 2003 08:57:48 -0000 1.20
>   +++ Request.java 5 Jun 2003 16:42:48 -0000 1.21
>   @@ -62,6 +62,7 @@
>
>    import java.io.IOException;
>    import java.util.Hashtable;
>   +import java.net.Socket;
>
>    import org.apache.tomcat.util.buf.ByteChunk;
>    import org.apache.tomcat.util.buf.MessageBytes;
>   @@ -137,6 +138,8 @@
>
>        private int remotePort;
>
>   +    private Socket socket;
>   +
>        private MessageBytes schemeMB = new MessageBytes();
>
>        private MessageBytes methodMB = new MessageBytes();
>   @@ -304,6 +307,23 @@
>            this.remotePort = port;
>        }
>
>   +    /**
>   +     * Sets the socket through which this request was received.
>   +     *
>   +     * @param socket The socket through which this request was received
>   +     */
>   +    public void setSocket(Socket socket) {
>   + this.socket = socket;
>   +    }
>   +
>   +    /**
>   +     * Gets the socket through which this request was received.
>   +     *
>   +     * @return The socket through which this request was received
>   +     */
>   +    public Socket getSocket() {
>   + return socket;
>   +    }
>
>        // -------------------- encoding/type --------------------
>
>
>
>
>   1.66      +1 -0
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
cessor.java
>
>   Index: Http11Processor.java
>   ===================================================================
>   RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Processor.java,v
>   retrieving revision 1.65
>   retrieving revision 1.66
>   diff -u -r1.65 -r1.66
>   --- Http11Processor.java 13 May 2003 22:45:58 -0000 1.65
>   +++ Http11Processor.java 5 Jun 2003 16:42:48 -0000 1.66
>   @@ -517,6 +517,7 @@
>        public void setSocket(Socket socket)
>            throws IOException {
>            this.socket = socket;
>   + this.request.setSocket(socket);
>        }
>
>        /**
>
>
>
>   1.27      +6 -5
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Pro
tocol.java
>
>   Index: Http11Protocol.java
>   ===================================================================
>   RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
/Http11Protocol.java,v
>   retrieving revision 1.26
>   retrieving revision 1.27
>   diff -u -r1.26 -r1.27
>   --- Http11Protocol.java 22 May 2003 04:51:03 -0000 1.26
>   +++ Http11Protocol.java 5 Jun 2003 16:42:48 -0000 1.27
>   @@ -86,8 +86,8 @@
>     */
>    public class Http11Protocol implements ProtocolHandler,
MBeanRegistration
>    {
>   -
>        public Http11Protocol() {
>   + cHandler = new Http11ConnectionHandler( this );
>            setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
>            setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
>            setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
>   @@ -99,9 +99,6 @@
>        protected static StringManager sm =
>            StringManager.getManager(Constants.Package);
>
>   -    Adapter adapter;
>   -    Http11ConnectionHandler cHandler=new Http11ConnectionHandler(
this );
>   -
>        /** Pass config info
>         */
>        public void setAttribute( String name, Object value ) {
>   @@ -220,6 +217,9 @@
>        private String reportedname;
>        private int socketCloseDelay=-1;
>        private boolean disableUploadTimeout = true;
>   +    private Adapter adapter;
>   +    private Http11ConnectionHandler cHandler;
>   +
>        /**
>         * Compression value.
>         */
>   @@ -442,7 +442,8 @@
>                return  thData;
>            }
>
>   -        public void processConnection(TcpConnection connection, Object
thData[]) {
>   +        public void processConnection(TcpConnection connection,
>   +       Object thData[]) {
>                Socket socket=null;
>                Http11Processor  processor=null;
>                try {
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


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