You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Eric Rescorla <ek...@rtfm.com> on 2002/05/08 20:16:23 UTC
Setting attributes via actions
I've been investigating the setting of SSL attributes via action hooks
and reached some unsettling conclusions.
(1) When you call getAttribute() from a servlet, this call filters
to the "facade" object of the CoyoteRequest.
(2) When you call o.a.c.Response.action(), you get
Http11Processor.action().
(3) The current code for ACTION_REQ_SSL_ATTRIBUTE in action() sets
attributes on Http11Processor.request, which is a different object
from the CoyoteRequest.facade. As a consequence, the SSL attributes
don't filter down to the servlet.
(4) The obvious fix to (3) is to simply pass the appropriate
facade to the action() method (in the Object params argument).
This requires casting the Object to
javax.servlet.http.HttpServletRequest or one of the classes/interfaces
which extend it.
Unfortunately, since HttpServletRequest doesn't seem to be in the
classpath when compiling Http11Processor, this doesn't
work. Obviously, I could adjust the classpath to make it available,
but I don't want to go violating layering boundaries for no good
reason.
So, questions:
(1) Have I missed some obvious approach here that will work?
(2) Should there really be two request objects in play here?
(3) Is this layering boundary important?
Comments from someone who understands this better than me
would be greatly appreciated.
-Ekr
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by Eric Rescorla <ek...@rtfm.com>.
Eric Rescorla <ek...@rtfm.com> writes:
> "Bill Barker" <wb...@wilshire.com> writes:
> > What I'm suggesting is to change o.a.c.tc4.CoyoteRequest.getAttribute to
> > something like:
> > <code>
> > public Object getAttribute(String name) {
> > return coyoteRequest.getAttribute(name);
> > }
> > </code>
> This works fine, but I'm wondering if maybe it would be better to do:
>
> public Object getAttribute(String name) {
> Object attr=attributes.get(name);
> if(attr) return(attr);
I was thinking in C here. It should say:
if(attr!=null) return(attr);
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by Eric Rescorla <ek...@rtfm.com>.
"Bill Barker" <wb...@wilshire.com> writes:
> What I'm suggesting is to change o.a.c.tc4.CoyoteRequest.getAttribute to
> something like:
> <code>
> public Object getAttribute(String name) {
> return coyoteRequest.getAttribute(name);
> }
> </code>
This works fine, but I'm wondering if maybe it would be better to do:
public Object getAttribute(String name) {
Object attr=attributes.get(name);
if(attr) return(attr);
return coyoteRequest.getAttribute(name);
}
That would let locally set attributes override those set via actions,
and should change behavior less than the change you suggest. I
don't understand Tomcat enough to be confident with the simpler
change--but if you say it's OK, I'm happy to believe you. :)
> It would also require some other changes in o.a.c.tc4.CoyoteRequest to be
> consistent.
What changes would we need here?
Thanks,
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Eric Rescorla" <ek...@rtfm.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, May 09, 2002 7:01 AM
Subject: Re: Setting attributes via actions
> "Bill Barker" <wb...@wilshire.com> writes:
> > From: "Eric Rescorla" <ek...@rtfm.com>
> > > So, questions:
> > > (1) Have I missed some obvious approach here that will work?
> >
> > What we do in TC 3.3 is to have the Tomcat3Request delegate
get/setAttribute
> > to the o.a.c.Request. I'm guessing that the o.a.c.tc4.CoyoteRequest
could
> > do something like that as well (and I believe that Jk2 needs this as
well to
> > pass the SSL attributes).
> If I understand what you're saying, I don't think this helps.
>
What I'm suggesting is to change o.a.c.tc4.CoyoteRequest.getAttribute to
something like:
<code>
public Object getAttribute(String name) {
return coyoteRequest.getAttribute(name);
}
</code>
It would also require some other changes in o.a.c.tc4.CoyoteRequest to be
consistent.
> Http11Processor.action() can't cast param to o.a.c.tc4.CoyoteRequest in
> order to call CoyoteRequest.setAttribute(), because that would
> require access o.a.c.HttpRequest and j.a.h.HttpServletRequest
> in the scope of Http11Processor.
>
> -Ekr
>
>
> --
> [Eric Rescorla ekr@rtfm.com]
> http://www.rtfm.com/
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by Eric Rescorla <ek...@rtfm.com>.
"Bill Barker" <wb...@wilshire.com> writes:
> From: "Eric Rescorla" <ek...@rtfm.com>
> > So, questions:
> > (1) Have I missed some obvious approach here that will work?
>
> What we do in TC 3.3 is to have the Tomcat3Request delegate get/setAttribute
> to the o.a.c.Request. I'm guessing that the o.a.c.tc4.CoyoteRequest could
> do something like that as well (and I believe that Jk2 needs this as well to
> pass the SSL attributes).
If I understand what you're saying, I don't think this helps.
Http11Processor.action() can't cast param to o.a.c.tc4.CoyoteRequest in
order to call CoyoteRequest.setAttribute(), because that would
require access o.a.c.HttpRequest and j.a.h.HttpServletRequest
in the scope of Http11Processor.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by co...@covalent.net.
On Wed, 8 May 2002, Bill Barker wrote:
> > (2) Should there really be two request objects in play here?
>
> It's pretty much necessary, since the o.a.c.Request is container agnostic.
> The Tomcat3Request & CoyoteRequest know about the container that they are
> running in. In particular, the Tomcat3Request is not instanceof
> HttpServletRequest, and won't have access to such a beast until very late.
It's also needed to prevent certain attacks ( if you have a single
Request and recycle, one webapp may hold the references and get
access to request for other webapps ). And is needed for
performance/design reasons - the lower level request works on
byte buffers, while the high level operates on strings. The
strings can be constructed only after the encoding is known,
and the Interceptor/Valve that detects that may need
various other information ( from mapping, session, etc ) -
it'll be a total mess with 1 request only.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Eric Rescorla" <ek...@rtfm.com>
To: <to...@jakarta.apache.org>
Sent: Wednesday, May 08, 2002 11:16 AM
Subject: Setting attributes via actions
> I've been investigating the setting of SSL attributes via action hooks
> and reached some unsettling conclusions.
>
> (1) When you call getAttribute() from a servlet, this call filters
> to the "facade" object of the CoyoteRequest.
>
> (2) When you call o.a.c.Response.action(), you get
> Http11Processor.action().
>
> (3) The current code for ACTION_REQ_SSL_ATTRIBUTE in action() sets
> attributes on Http11Processor.request, which is a different object
> from the CoyoteRequest.facade. As a consequence, the SSL attributes
> don't filter down to the servlet.
>
> (4) The obvious fix to (3) is to simply pass the appropriate
> facade to the action() method (in the Object params argument).
> This requires casting the Object to
> javax.servlet.http.HttpServletRequest or one of the classes/interfaces
> which extend it.
>
> Unfortunately, since HttpServletRequest doesn't seem to be in the
> classpath when compiling Http11Processor, this doesn't
> work. Obviously, I could adjust the classpath to make it available,
> but I don't want to go violating layering boundaries for no good
> reason.
>
> So, questions:
> (1) Have I missed some obvious approach here that will work?
What we do in TC 3.3 is to have the Tomcat3Request delegate get/setAttribute
to the o.a.c.Request. I'm guessing that the o.a.c.tc4.CoyoteRequest could
do something like that as well (and I believe that Jk2 needs this as well to
pass the SSL attributes).
> (2) Should there really be two request objects in play here?
It's pretty much necessary, since the o.a.c.Request is container agnostic.
The Tomcat3Request & CoyoteRequest know about the container that they are
running in. In particular, the Tomcat3Request is not instanceof
HttpServletRequest, and won't have access to such a beast until very late.
> (3) Is this layering boundary important?
>
> Comments from someone who understands this better than me
> would be greatly appreciated.
>
> -Ekr
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: <co...@covalent.net>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, May 08, 2002 11:49 AM
Subject: Re: Setting attributes via actions
> On Wed, 8 May 2002, Eric Rescorla wrote:
>
> > (1) When you call getAttribute() from a servlet, this call filters
> > to the "facade" object of the CoyoteRequest.
> >
> > (3) The current code for ACTION_REQ_SSL_ATTRIBUTE in action() sets
> > attributes on Http11Processor.request, which is a different object
> > from the CoyoteRequest.facade. As a consequence, the SSL attributes
> > don't filter down to the servlet.
> >
> > (4) The obvious fix to (3) is to simply pass the appropriate
> > facade to the action() method (in the Object params argument).
> > This requires casting the Object to
> > javax.servlet.http.HttpServletRequest or one of the classes/interfaces
> > which extend it.
>
> I think the right fix would be in facade, by calling the action
> if the attribute is not available.
>
> Extra benefit - you get 'lazy evaluation', very good for performance
> ( since most servlets will not actually need this info ).
Doesn't really work in Catalina, since you can wrap requests in 2.3. In
particular, the wrapper used by the RequestDispatcher overrides
get/setAttribute.
>
> Costin
>
>
> >
> > Unfortunately, since HttpServletRequest doesn't seem to be in the
> > classpath when compiling Http11Processor, this doesn't
> > work. Obviously, I could adjust the classpath to make it available,
> > but I don't want to go violating layering boundaries for no good
> > reason.
> >
> > So, questions:
> > (1) Have I missed some obvious approach here that will work?
> > (2) Should there really be two request objects in play here?
> > (3) Is this layering boundary important?
> >
> > Comments from someone who understands this better than me
> > would be greatly appreciated.
> >
> > -Ekr
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Setting attributes via actions
Posted by co...@covalent.net.
On Wed, 8 May 2002, Eric Rescorla wrote:
> (1) When you call getAttribute() from a servlet, this call filters
> to the "facade" object of the CoyoteRequest.
>
> (3) The current code for ACTION_REQ_SSL_ATTRIBUTE in action() sets
> attributes on Http11Processor.request, which is a different object
> from the CoyoteRequest.facade. As a consequence, the SSL attributes
> don't filter down to the servlet.
>
> (4) The obvious fix to (3) is to simply pass the appropriate
> facade to the action() method (in the Object params argument).
> This requires casting the Object to
> javax.servlet.http.HttpServletRequest or one of the classes/interfaces
> which extend it.
I think the right fix would be in facade, by calling the action
if the attribute is not available.
Extra benefit - you get 'lazy evaluation', very good for performance
( since most servlets will not actually need this info ).
Costin
>
> Unfortunately, since HttpServletRequest doesn't seem to be in the
> classpath when compiling Http11Processor, this doesn't
> work. Obviously, I could adjust the classpath to make it available,
> but I don't want to go violating layering boundaries for no good
> reason.
>
> So, questions:
> (1) Have I missed some obvious approach here that will work?
> (2) Should there really be two request objects in play here?
> (3) Is this layering boundary important?
>
> Comments from someone who understands this better than me
> would be greatly appreciated.
>
> -Ekr
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>