Ok, I decided to modify the Http11Processor, since the SSL trick is
kindof too hacky for my taste. It sets the attribute, and it's fine now.
Another issue came up though with flushing the OutputStream - and this
is something unrelated to the previous conversation.
So in org.apache.coyote.http11.InternalOutputBuffer when endRequest() is
called - on line 442 socketBuffer.flushBuffer() will in turn call
realWriteBytes which does a write on the actual outputStream, but
nothing will ever call flush() on the outputStream. This is not
noticeable in case of the normal java.net.SocketOutputStream (it's
unbuffered from what i can tell), but since I have overriden the
outputstream and my class needs to be either flush()'ed or close()'ed,
as a result my stuff is never sent back to the client, hanging the
requests.
I would think it's reasonable to expect a flush at some point on the
OutputStream when ending the request, no? This lack of flushing in not
present in the HttpConnector, in tomcat 4.
thank you
-anton
On Fri, 2004-04-02 at 17:14, Bill Barker wrote:
> ----- Original Message -----
> From: "Anton Ushakov" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
