You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Peter Harrison <pe...@nothingbutnet.co.nz> on 2003/10/16 00:44:06 UTC
Resources only working in a specific context.
I had an issue with 4.1.27 with having a DefaultContext define a JDBC
Resource. If the resource is defined in a specific Context everything is
fine, but move it into DefaultContext or GobalResources and you get
NullPointer Exceptions and so on.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23634
I was thinking about getting Tomcat source and looking at this myself - but
I'm not sure where to start looking?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: How to make CLIENT-CERT protection work?
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jan Luehe" <Ja...@Sun.COM>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, October 15, 2003 6:38 PM
Subject: How to make CLIENT-CERT protection work?
> Consider the following scenario:
>
> 1. Client sends POST request (with content type other than
> "application/x-www-form-urlencoded") to SSL-enabled server (with
> client auth turned off).
>
> 2. Server parses request header, and determines that the resource
> identified by the request-URI is CLIENT-CERT protected.
>
> 3. Server's SSLAuthenticator valve reinitiates SSL handshake, w/
> client auth turned on.
>
> 4. The server sends its HelloRequest, and expects to read the client's
> ClientHello. However, what it gets is the POST request's body which
> hadn't been read yet.
>
> 5. SSL handshake fails.
>
>
> In order to avoid this problem, SSLAuthenticator.authenticate()
> "clears" the socket in the case of a POST request by reading the POST
> request's body *before* reinitiating the handshake. To read the POST
> body, it calls CoyoteRequest.getParameterMap(), which reads and
> processes the POST body only if the content type equals
> "application/x-www-form-urlencoded".
>
> Therefore, the SSL re-handshake works according to plan if the content
> type equals "application/x-www-form-urlencoded", but fails for any
> other content type.
>
> Should we always read the POST body in getParameterMap(), and cache it
> in a byte[] if content type is different from
> "application/x-www-form-urlencoded", and have
> CoyoteRequest.getInputStream()/getReader() return wrappers around this
> byte[]?
>
> Any better suggestions?
It would probably be better to remove the POST check from SSLAuthenticator,
and move it to Http11Processor.action. Then when it is processing
ACTION_REQ_SSL_CERTIFICATE, it simply need to add a new InputFilter (say,
BufferedInputFilter) that does a full read of the Request data.
>
> Thanks,
>
>
> Jan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
How to make CLIENT-CERT protection work?
Posted by Jan Luehe <Ja...@Sun.COM>.
Consider the following scenario:
1. Client sends POST request (with content type other than
"application/x-www-form-urlencoded") to SSL-enabled server (with
client auth turned off).
2. Server parses request header, and determines that the resource
identified by the request-URI is CLIENT-CERT protected.
3. Server's SSLAuthenticator valve reinitiates SSL handshake, w/
client auth turned on.
4. The server sends its HelloRequest, and expects to read the client's
ClientHello. However, what it gets is the POST request's body which
hadn't been read yet.
5. SSL handshake fails.
In order to avoid this problem, SSLAuthenticator.authenticate()
"clears" the socket in the case of a POST request by reading the POST
request's body *before* reinitiating the handshake. To read the POST
body, it calls CoyoteRequest.getParameterMap(), which reads and
processes the POST body only if the content type equals
"application/x-www-form-urlencoded".
Therefore, the SSL re-handshake works according to plan if the content
type equals "application/x-www-form-urlencoded", but fails for any
other content type.
Should we always read the POST body in getParameterMap(), and cache it
in a byte[] if content type is different from
"application/x-www-form-urlencoded", and have
CoyoteRequest.getInputStream()/getReader() return wrappers around this
byte[]?
Any better suggestions?
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org