You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Anton Ushakov <an...@stanford.edu> on 2004/03/24 22:49:10 UTC
Coyote's ServerSocketFactory problem
Hello Tomcat Developers!
I'm working with Tomcat 4.1.29 and I'd like to use my own
ServerSocketFactory, as I'm working on a custom implementation of httpg
(HTTP over GSSAPI authenticated sockets). This seems impossible by
design, which I think may be a bug.
Instead of using the deprecated HttpConnector I'm trying to use the
CoyoteConnector. The trouble is, with CoyoteConnector there is no way to
override the ServerSocketFactory to be used. My
CustomServerSocketFactory implements
org.apache.catalina.net.ServerSocketFactory, and I tried using the
following in server.xml:
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="6688" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="100" debug="50" connectionTimeout="20000"
scheme="httpg"
useURIValidationHack="false" disableUploadTimeout="true">
<Factory className="my.own.CustomServerSocketFactory"
principal="service/name@stanford.edu"
keytab="/etc/keytab" />
</Connector>
This will successfully set the factory in CoyoteConnector, but it does
NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual
factory getting used at runtime is the default one in Http11Protocol.
The CoyoteConnector's "factory" datamember is totally ignored.
I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java
around lines 1111-1135 there should be something to propagate the socket
factory to the protocolHandler. However even then, Http11Protocol
insists on using org.apache.tomcat.util.net.ServerSocketFactory, not
the org.apache.catalina.net.ServerSocketFactory required by the
CoyoteConnector. (?)
Bottom line - how is one supposed to specify a custom
ServerSocketFactory with the CoyoteConnector?
Bill Barker has emailed me a suggestion of using the
socketFactory="fully.qualified.name.of.MyOwnServerSocketFactory"
attribute on the <Connector> element. While I appreciate the response,
that doesn't set the factory datamember in the Connector, and neither
does it change the socketFactory in the protocolHandler.
I appreciate your help on this
-anton
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Coyote's ServerSocketFactory problem
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Anton Ushakov" <an...@stanford.edu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, April 02, 2004 10:46 AM
Subject: Re: Coyote's ServerSocketFactory problem
> First I must say you've been extremely helpful, thank you for your
> prompt responses! I hate to bug you but I had another implementation
> question. I looked at JSSESocketFactory and how SSL is done in the
> connector, but it doesnt address one particular issue I'm having.
>
> Basically I have JAAS (GSSAPI) authentication done inside the Socket
> that my SocketFactory makes. Let's call it GssSocket, and it uses
> GssInputStream GssOutputStream for the authenticated & encrypted
> communication. Inside the GssSocket I establish the identity
> (principal) of the incoming request, but have no way to set it into the
> CoyoteRequest so it can get passed to the target Servlets through the
> HttpServletRequest. Since all the servlet sees is the
> CoyoteRequestFacade, I cannot get access to either the GssSocket, or the
> GssStreams - the only places where the principal of the user is known.
>
> It looks like I can't avoid extending one of the Coyote classes after
> all. What would you suggest to override to be able to extract a string
> from the Socket and set it as an attribute for the servlets to get at?
> I'm sorry if this is getting too hairy, but any advice would be great.
>
It's probably possible to do what you want without much, if any, modifying
of Tomcat code. If you were to setup a full "SSLImplementation" to
implement your socket factory, then you could have your code return the
identity information in response to
'request.getAttribute("org.apache.coyote.request.X509Certificate")'. This
should work because nothing in Tomcat outside of the SSLImplementation
understands anything about SSL, so it won't really care that you aren't
implementing real SSL. This method is a little hackish, but it has the
advantage that you don't have to modify any of Tomcat's code to get it to
work. The downside is that you have to implement a minimum of three
classes, even if you can make most of the methods to be dummies. You'd also
need to worry about the scheme getting set to "https", but I could be talked
into modifying that.
Otherwise, you'd probably have to modify Http11Processor (about the only
class that has access to both the Request and the Socket :) to set the
attributes you want on the Request.
> thanks
> -anton
>
>
> On Thu, 2004-04-01 at 13:32, Bill Barker wrote:
> > ----- Original Message -----
> > From: "Anton Ushakov" <an...@stanford.edu>
> > To: "Tomcat Developers List" <to...@jakarta.apache.org>
> > Sent: Wednesday, March 31, 2004 10:59 PM
> > Subject: Re: Coyote's ServerSocketFactory problem
> >
> >
> > > Alright, thanks Bill. I have nothing against Tomcat5 and indeed the
> > > socketFactory="my.factory" attribute works. But is there any way to
pass
> > > custom parameters to the factory from the conf file? With a <Factory>
> > > element it was possible but with a single attribute am I out of luck?
> > > All this IntrospectionUtils business is confusing...
> > >
> >
> > The way this works is that all of the <Connector> attributes are passed
on
> > to the Protocol. In the case of the Http11Protocol, the attributes are
then
> > passed on to the SocketFactory (via calling the setAttribute method of
> > o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your
> > parameters on the <Connector>, and they will end up passed to your
> > SocketFactory. You can look at JSSESocketFactory to see how Tomcat
handles
> > this for the default SSL connector.
> >
> > >
> > > On Fri, 2004-03-26 at 18:03, Bill Barker wrote:
> > > > ----- Original Message -----
> > > > From: "Anton Ushakov" <an...@stanford.edu>
> > > > To: "Tomcat Developers List" <to...@jakarta.apache.org>
> > > > Sent: Friday, March 26, 2004 4:24 PM
> > > > Subject: Re: Coyote's ServerSocketFactory problem
> > > >
> > > >
> > > > > Should I make a bug entry for this? I wanted to get someone from
the
> > > > > tomcat dev team to see if I was missing something before flagging
this
> > > > > as a bug.
> > > > >
> > > >
> > > > The Catalina SocketFactory is deprecated for use with Coyote in 5.x,
and
> > it
> > > > would probably should be for 4.x as well except for the fact that it
is
> > > > still required to set SSL attributes. This means that anything
> > involving
> > > > this SocketFactory will just get marked as WONTFIX.
> > > >
> > > > Passing the socketFactory attribute on to the Protocol might be
> > something
> > > > (except for the fact that it is working in 5.x means it may not get
a
> > lot of
> > > > attention :).
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> > >
> >
> >
> > ______________________________________________________________________
> > This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL. If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.
> >
> > In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
> >
> >
> > ______________________________________________________________________
> > ---------------------------------------------------------------------
> > 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: Coyote's ServerSocketFactory problem
Posted by Anton Ushakov <an...@stanford.edu>.
First I must say you've been extremely helpful, thank you for your
prompt responses! I hate to bug you but I had another implementation
question. I looked at JSSESocketFactory and how SSL is done in the
connector, but it doesnt address one particular issue I'm having.
Basically I have JAAS (GSSAPI) authentication done inside the Socket
that my SocketFactory makes. Let's call it GssSocket, and it uses
GssInputStream GssOutputStream for the authenticated & encrypted
communication. Inside the GssSocket I establish the identity
(principal) of the incoming request, but have no way to set it into the
CoyoteRequest so it can get passed to the target Servlets through the
HttpServletRequest. Since all the servlet sees is the
CoyoteRequestFacade, I cannot get access to either the GssSocket, or the
GssStreams - the only places where the principal of the user is known.
It looks like I can't avoid extending one of the Coyote classes after
all. What would you suggest to override to be able to extract a string
from the Socket and set it as an attribute for the servlets to get at?
I'm sorry if this is getting too hairy, but any advice would be great.
thanks
-anton
On Thu, 2004-04-01 at 13:32, Bill Barker wrote:
> ----- Original Message -----
> From: "Anton Ushakov" <an...@stanford.edu>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Wednesday, March 31, 2004 10:59 PM
> Subject: Re: Coyote's ServerSocketFactory problem
>
>
> > Alright, thanks Bill. I have nothing against Tomcat5 and indeed the
> > socketFactory="my.factory" attribute works. But is there any way to pass
> > custom parameters to the factory from the conf file? With a <Factory>
> > element it was possible but with a single attribute am I out of luck?
> > All this IntrospectionUtils business is confusing...
> >
>
> The way this works is that all of the <Connector> attributes are passed on
> to the Protocol. In the case of the Http11Protocol, the attributes are then
> passed on to the SocketFactory (via calling the setAttribute method of
> o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your
> parameters on the <Connector>, and they will end up passed to your
> SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles
> this for the default SSL connector.
>
> >
> > On Fri, 2004-03-26 at 18:03, Bill Barker wrote:
> > > ----- Original Message -----
> > > From: "Anton Ushakov" <an...@stanford.edu>
> > > To: "Tomcat Developers List" <to...@jakarta.apache.org>
> > > Sent: Friday, March 26, 2004 4:24 PM
> > > Subject: Re: Coyote's ServerSocketFactory problem
> > >
> > >
> > > > Should I make a bug entry for this? I wanted to get someone from the
> > > > tomcat dev team to see if I was missing something before flagging this
> > > > as a bug.
> > > >
> > >
> > > The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and
> it
> > > would probably should be for 4.x as well except for the fact that it is
> > > still required to set SSL attributes. This means that anything
> involving
> > > this SocketFactory will just get marked as WONTFIX.
> > >
> > > Passing the socketFactory attribute on to the Protocol might be
> something
> > > (except for the fact that it is working in 5.x means it may not get a
> lot of
> > > attention :).
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ______________________________________________________________________
> This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> ______________________________________________________________________
> ---------------------------------------------------------------------
> 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: Coyote's ServerSocketFactory problem
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Anton Ushakov" <an...@stanford.edu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, March 31, 2004 10:59 PM
Subject: Re: Coyote's ServerSocketFactory problem
> Alright, thanks Bill. I have nothing against Tomcat5 and indeed the
> socketFactory="my.factory" attribute works. But is there any way to pass
> custom parameters to the factory from the conf file? With a <Factory>
> element it was possible but with a single attribute am I out of luck?
> All this IntrospectionUtils business is confusing...
>
The way this works is that all of the <Connector> attributes are passed on
to the Protocol. In the case of the Http11Protocol, the attributes are then
passed on to the SocketFactory (via calling the setAttribute method of
o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your
parameters on the <Connector>, and they will end up passed to your
SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles
this for the default SSL connector.
>
> On Fri, 2004-03-26 at 18:03, Bill Barker wrote:
> > ----- Original Message -----
> > From: "Anton Ushakov" <an...@stanford.edu>
> > To: "Tomcat Developers List" <to...@jakarta.apache.org>
> > Sent: Friday, March 26, 2004 4:24 PM
> > Subject: Re: Coyote's ServerSocketFactory problem
> >
> >
> > > Should I make a bug entry for this? I wanted to get someone from the
> > > tomcat dev team to see if I was missing something before flagging this
> > > as a bug.
> > >
> >
> > The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and
it
> > would probably should be for 4.x as well except for the fact that it is
> > still required to set SSL attributes. This means that anything
involving
> > this SocketFactory will just get marked as WONTFIX.
> >
> > Passing the socketFactory attribute on to the Protocol might be
something
> > (except for the fact that it is working in 5.x means it may not get a
lot of
> > attention :).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Coyote's ServerSocketFactory problem
Posted by Anton Ushakov <an...@stanford.edu>.
Alright, thanks Bill. I have nothing against Tomcat5 and indeed the
socketFactory="my.factory" attribute works. But is there any way to pass
custom parameters to the factory from the conf file? With a <Factory>
element it was possible but with a single attribute am I out of luck?
All this IntrospectionUtils business is confusing...
On Fri, 2004-03-26 at 18:03, Bill Barker wrote:
> ----- Original Message -----
> From: "Anton Ushakov" <an...@stanford.edu>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Friday, March 26, 2004 4:24 PM
> Subject: Re: Coyote's ServerSocketFactory problem
>
>
> > Should I make a bug entry for this? I wanted to get someone from the
> > tomcat dev team to see if I was missing something before flagging this
> > as a bug.
> >
>
> The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it
> would probably should be for 4.x as well except for the fact that it is
> still required to set SSL attributes. This means that anything involving
> this SocketFactory will just get marked as WONTFIX.
>
> Passing the socketFactory attribute on to the Protocol might be something
> (except for the fact that it is working in 5.x means it may not get a lot of
> attention :).
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Coyote's ServerSocketFactory problem
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Anton Ushakov" <an...@stanford.edu>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, March 26, 2004 4:24 PM
Subject: Re: Coyote's ServerSocketFactory problem
> Should I make a bug entry for this? I wanted to get someone from the
> tomcat dev team to see if I was missing something before flagging this
> as a bug.
>
The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it
would probably should be for 4.x as well except for the fact that it is
still required to set SSL attributes. This means that anything involving
this SocketFactory will just get marked as WONTFIX.
Passing the socketFactory attribute on to the Protocol might be something
(except for the fact that it is working in 5.x means it may not get a lot of
attention :).
> thank you
> -anton
>
>
>
> On Wed, 2004-03-24 at 17:16, Anton Ushakov wrote:
> > In CoyoteConnector.initialize() there's an assumption that if the
> > factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL,
> > and it sets secure=true. Then in
> > Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java,
> > it interprets that "secure" flag as SSL and uses SSLImplementation to
> > get the socket factory.
> >
> > In our case, the scheme is not ssl, so unfortunately this doesn't work.
> >
> > Http11Protocol just wasn't written to accept a socket factory object,
> > and the one it makes from the passed classname is of a different type
> > than CoyoteConnector's socket factory. It's not enough to make the types
> > the same, it really should take a whole factory object, since the
> > factory's attributes need to be set from the conf.
> >
> >
> > On Wed, 2004-03-24 at 16:03, Jim Hopp wrote:
> > > We have a similar need (though for a different reason) and extend
> > > CoyoteServerSocketFactory. We're running TC 4.1.29.
> > >
> > > Here's our Connector element:
> > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> > > port="7002"
> > > scheme="https"
> > > secure="true"
> > > address="127.0.0.1"
> > > enableLookups="false">
> > > <Factory className="nyw.catalina.NYWCoyoteServerSocketFactory"
> > > clientAuth="true"/>
> > > </Connector>
> > >
> > > Works great.
> > >
> > > -Jim
> > >
> > > Anton Ushakov wrote:
> > > > Hello Tomcat Developers!
> > > >
> > > > I'm working with Tomcat 4.1.29 and I'd like to use my own
> > > > ServerSocketFactory, as I'm working on a custom implementation of
httpg
> > > > (HTTP over GSSAPI authenticated sockets). This seems impossible by
> > > > design, which I think may be a bug.
> > > >
> > > > Instead of using the deprecated HttpConnector I'm trying to use the
> > > > CoyoteConnector. The trouble is, with CoyoteConnector there is no
way to
> > > > override the ServerSocketFactory to be used. My
> > > > CustomServerSocketFactory implements
> > > > org.apache.catalina.net.ServerSocketFactory, and I tried using the
> > > > following in server.xml:
> > > >
> > > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> > > > port="6688" minProcessors="5" maxProcessors="75"
> > > > enableLookups="true" redirectPort="8443"
> > > > acceptCount="100" debug="50"
connectionTimeout="20000"
> > > > scheme="httpg"
> > > > useURIValidationHack="false"
disableUploadTimeout="true">
> > > > <Factory className="my.own.CustomServerSocketFactory"
> > > > principal="service/name@stanford.edu"
> > > > keytab="/etc/keytab" />
> > > > </Connector>
> > > >
> > > >
> > > > This will successfully set the factory in CoyoteConnector, but it
does
> > > > NOT propagate to org.apache.coyote.http11.Http11Protocol, and the
actual
> > > > factory getting used at runtime is the default one in
Http11Protocol.
> > > > The CoyoteConnector's "factory" datamember is totally ignored.
> > > >
> > > > I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java
> > > > around lines 1111-1135 there should be something to propagate the
socket
> > > > factory to the protocolHandler. However even then, Http11Protocol
> > > > insists on using org.apache.tomcat.util.net.ServerSocketFactory,
not
> > > > the org.apache.catalina.net.ServerSocketFactory required by the
> > > > CoyoteConnector. (?)
> > > >
> > > > Bottom line - how is one supposed to specify a custom
> > > > ServerSocketFactory with the CoyoteConnector?
> > > >
> > > > Bill Barker has emailed me a suggestion of using the
> > > > socketFactory="fully.qualified.name.of.MyOwnServerSocketFactory"
> > > > attribute on the <Connector> element. While I appreciate the
response,
> > > > that doesn't set the factory datamember in the Connector, and
neither
> > > > does it change the socketFactory in the protocolHandler.
> > > >
> > > > I appreciate your help on this
> > > >
> > > > -anton
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > 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
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Coyote's ServerSocketFactory problem
Posted by Anton Ushakov <an...@stanford.edu>.
Should I make a bug entry for this? I wanted to get someone from the
tomcat dev team to see if I was missing something before flagging this
as a bug.
thank you
-anton
On Wed, 2004-03-24 at 17:16, Anton Ushakov wrote:
> In CoyoteConnector.initialize() there's an assumption that if the
> factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL,
> and it sets secure=true. Then in
> Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java,
> it interprets that "secure" flag as SSL and uses SSLImplementation to
> get the socket factory.
>
> In our case, the scheme is not ssl, so unfortunately this doesn't work.
>
> Http11Protocol just wasn't written to accept a socket factory object,
> and the one it makes from the passed classname is of a different type
> than CoyoteConnector's socket factory. It's not enough to make the types
> the same, it really should take a whole factory object, since the
> factory's attributes need to be set from the conf.
>
>
> On Wed, 2004-03-24 at 16:03, Jim Hopp wrote:
> > We have a similar need (though for a different reason) and extend
> > CoyoteServerSocketFactory. We're running TC 4.1.29.
> >
> > Here's our Connector element:
> > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> > port="7002"
> > scheme="https"
> > secure="true"
> > address="127.0.0.1"
> > enableLookups="false">
> > <Factory className="nyw.catalina.NYWCoyoteServerSocketFactory"
> > clientAuth="true"/>
> > </Connector>
> >
> > Works great.
> >
> > -Jim
> >
> > Anton Ushakov wrote:
> > > Hello Tomcat Developers!
> > >
> > > I'm working with Tomcat 4.1.29 and I'd like to use my own
> > > ServerSocketFactory, as I'm working on a custom implementation of httpg
> > > (HTTP over GSSAPI authenticated sockets). This seems impossible by
> > > design, which I think may be a bug.
> > >
> > > Instead of using the deprecated HttpConnector I'm trying to use the
> > > CoyoteConnector. The trouble is, with CoyoteConnector there is no way to
> > > override the ServerSocketFactory to be used. My
> > > CustomServerSocketFactory implements
> > > org.apache.catalina.net.ServerSocketFactory, and I tried using the
> > > following in server.xml:
> > >
> > > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> > > port="6688" minProcessors="5" maxProcessors="75"
> > > enableLookups="true" redirectPort="8443"
> > > acceptCount="100" debug="50" connectionTimeout="20000"
> > > scheme="httpg"
> > > useURIValidationHack="false" disableUploadTimeout="true">
> > > <Factory className="my.own.CustomServerSocketFactory"
> > > principal="service/name@stanford.edu"
> > > keytab="/etc/keytab" />
> > > </Connector>
> > >
> > >
> > > This will successfully set the factory in CoyoteConnector, but it does
> > > NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual
> > > factory getting used at runtime is the default one in Http11Protocol.
> > > The CoyoteConnector's "factory" datamember is totally ignored.
> > >
> > > I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java
> > > around lines 1111-1135 there should be something to propagate the socket
> > > factory to the protocolHandler. However even then, Http11Protocol
> > > insists on using org.apache.tomcat.util.net.ServerSocketFactory, not
> > > the org.apache.catalina.net.ServerSocketFactory required by the
> > > CoyoteConnector. (?)
> > >
> > > Bottom line - how is one supposed to specify a custom
> > > ServerSocketFactory with the CoyoteConnector?
> > >
> > > Bill Barker has emailed me a suggestion of using the
> > > socketFactory="fully.qualified.name.of.MyOwnServerSocketFactory"
> > > attribute on the <Connector> element. While I appreciate the response,
> > > that doesn't set the factory datamember in the Connector, and neither
> > > does it change the socketFactory in the protocolHandler.
> > >
> > > I appreciate your help on this
> > >
> > > -anton
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Coyote's ServerSocketFactory problem
Posted by Anton Ushakov <an...@stanford.edu>.
In CoyoteConnector.initialize() there's an assumption that if the
factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL,
and it sets secure=true. Then in
Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java,
it interprets that "secure" flag as SSL and uses SSLImplementation to
get the socket factory.
In our case, the scheme is not ssl, so unfortunately this doesn't work.
Http11Protocol just wasn't written to accept a socket factory object,
and the one it makes from the passed classname is of a different type
than CoyoteConnector's socket factory. It's not enough to make the types
the same, it really should take a whole factory object, since the
factory's attributes need to be set from the conf.
On Wed, 2004-03-24 at 16:03, Jim Hopp wrote:
> We have a similar need (though for a different reason) and extend
> CoyoteServerSocketFactory. We're running TC 4.1.29.
>
> Here's our Connector element:
> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> port="7002"
> scheme="https"
> secure="true"
> address="127.0.0.1"
> enableLookups="false">
> <Factory className="nyw.catalina.NYWCoyoteServerSocketFactory"
> clientAuth="true"/>
> </Connector>
>
> Works great.
>
> -Jim
>
> Anton Ushakov wrote:
> > Hello Tomcat Developers!
> >
> > I'm working with Tomcat 4.1.29 and I'd like to use my own
> > ServerSocketFactory, as I'm working on a custom implementation of httpg
> > (HTTP over GSSAPI authenticated sockets). This seems impossible by
> > design, which I think may be a bug.
> >
> > Instead of using the deprecated HttpConnector I'm trying to use the
> > CoyoteConnector. The trouble is, with CoyoteConnector there is no way to
> > override the ServerSocketFactory to be used. My
> > CustomServerSocketFactory implements
> > org.apache.catalina.net.ServerSocketFactory, and I tried using the
> > following in server.xml:
> >
> > <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> > port="6688" minProcessors="5" maxProcessors="75"
> > enableLookups="true" redirectPort="8443"
> > acceptCount="100" debug="50" connectionTimeout="20000"
> > scheme="httpg"
> > useURIValidationHack="false" disableUploadTimeout="true">
> > <Factory className="my.own.CustomServerSocketFactory"
> > principal="service/name@stanford.edu"
> > keytab="/etc/keytab" />
> > </Connector>
> >
> >
> > This will successfully set the factory in CoyoteConnector, but it does
> > NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual
> > factory getting used at runtime is the default one in Http11Protocol.
> > The CoyoteConnector's "factory" datamember is totally ignored.
> >
> > I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java
> > around lines 1111-1135 there should be something to propagate the socket
> > factory to the protocolHandler. However even then, Http11Protocol
> > insists on using org.apache.tomcat.util.net.ServerSocketFactory, not
> > the org.apache.catalina.net.ServerSocketFactory required by the
> > CoyoteConnector. (?)
> >
> > Bottom line - how is one supposed to specify a custom
> > ServerSocketFactory with the CoyoteConnector?
> >
> > Bill Barker has emailed me a suggestion of using the
> > socketFactory="fully.qualified.name.of.MyOwnServerSocketFactory"
> > attribute on the <Connector> element. While I appreciate the response,
> > that doesn't set the factory datamember in the Connector, and neither
> > does it change the socketFactory in the protocolHandler.
> >
> > I appreciate your help on this
> >
> > -anton
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Coyote's ServerSocketFactory problem
Posted by Jim Hopp <ji...@netyourwork.com>.
We have a similar need (though for a different reason) and extend
CoyoteServerSocketFactory. We're running TC 4.1.29.
Here's our Connector element:
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="7002"
scheme="https"
secure="true"
address="127.0.0.1"
enableLookups="false">
<Factory className="nyw.catalina.NYWCoyoteServerSocketFactory"
clientAuth="true"/>
</Connector>
Works great.
-Jim
Anton Ushakov wrote:
> Hello Tomcat Developers!
>
> I'm working with Tomcat 4.1.29 and I'd like to use my own
> ServerSocketFactory, as I'm working on a custom implementation of httpg
> (HTTP over GSSAPI authenticated sockets). This seems impossible by
> design, which I think may be a bug.
>
> Instead of using the deprecated HttpConnector I'm trying to use the
> CoyoteConnector. The trouble is, with CoyoteConnector there is no way to
> override the ServerSocketFactory to be used. My
> CustomServerSocketFactory implements
> org.apache.catalina.net.ServerSocketFactory, and I tried using the
> following in server.xml:
>
> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
> port="6688" minProcessors="5" maxProcessors="75"
> enableLookups="true" redirectPort="8443"
> acceptCount="100" debug="50" connectionTimeout="20000"
> scheme="httpg"
> useURIValidationHack="false" disableUploadTimeout="true">
> <Factory className="my.own.CustomServerSocketFactory"
> principal="service/name@stanford.edu"
> keytab="/etc/keytab" />
> </Connector>
>
>
> This will successfully set the factory in CoyoteConnector, but it does
> NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual
> factory getting used at runtime is the default one in Http11Protocol.
> The CoyoteConnector's "factory" datamember is totally ignored.
>
> I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java
> around lines 1111-1135 there should be something to propagate the socket
> factory to the protocolHandler. However even then, Http11Protocol
> insists on using org.apache.tomcat.util.net.ServerSocketFactory, not
> the org.apache.catalina.net.ServerSocketFactory required by the
> CoyoteConnector. (?)
>
> Bottom line - how is one supposed to specify a custom
> ServerSocketFactory with the CoyoteConnector?
>
> Bill Barker has emailed me a suggestion of using the
> socketFactory="fully.qualified.name.of.MyOwnServerSocketFactory"
> attribute on the <Connector> element. While I appreciate the response,
> that doesn't set the factory datamember in the Connector, and neither
> does it change the socketFactory in the protocolHandler.
>
> I appreciate your help on this
>
> -anton
>
>
>
> ---------------------------------------------------------------------
> 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