tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: JkSetEnv and Servlet Filters
Date Sun, 04 May 2008 15:56:19 GMT
Keith Ealanta schrieb:
> Rainer Jung wrote:
>> Hi Keith,
>>
>> Keith Ealanta schrieb:
>>> Can anyone advise me how to access the attributes set in an http 
>>> request using JkSetEnv?
>>
>> I just tried it again, it works for me.
>>
>>> Specifically I'm using JkSetEnv on Apache2.0 to set a number of 
>>> attributes in the request.
>>> I have captured the mod_jk packets (on port 8009) and they contain 
>>> the items I've set in the attributes section as req_attribute type 
>>> (code 0x0A)
>>> When I access the ServletRequest object I cannot find this data 
>>> anywhere. I've downloaded a number of ServletRequest display filters 
>>> and none of them show the data either.
>>
>> I simply retrieve any attribute via
>>   request.getAttribute(nameOfTheAttribute)
>> from the ServletRequest.
>>
>>> Are these attributes only useful for setting specific values the 
>>> system understands, is there some other way for me to access these 
>>> values from the ServletRequest object in Tomcat, or alternately is it 
>>> possible there is some error in mod_jk or Tomcat such that the data 
>>> is never extracted (if it even should be).
>>
>> It works for me. Which versions of mod_jk and Tomcat are you using?
> Mod_jk: 1:1.2.18-3

Aha, although I'm not currently aware of any specific bug related to 
JkEnvVar, you should update mod_jk. We are currently at 1.2.26, which 
runs fine.

> Apache2: Apache/2.0.54
> 
> /opt/tomcat/bin/version.sh
> Server version: Apache Tomcat/5.5.17
> Server built:   Apr 14 2006 02:08:29
> Server number:  5.5.17.0
> OS Name:        Linux
> OS Version:     2.6.18-4-xen-vserver-amd64
> Architecture:   i386
> JVM Version:    1.6.0_03-b05
> JVM Vendor:     Sun Microsystems Inc.
> 
>> How does your JK config look like (yes, I know you already wrote you 
>> can see the attribute set in the debug log, but let's make sure)?
> Extract from file /etc/apache2/conf.d/player.conf
> # JK
> JkEnvVar AUTH_TYPE "<UNSET>"
> JkEnvVar REMOTE_USER "<UNSET>"
> JkEnvVar SINA_CUSTOMER "<UNSET>"
> JkEnvVar SINA_EA "<UNSET>"
> JkEnvVar SINA_USER_GROUP_NAME "<UNSET>"
> JkWorkersFile   /etc/libapache2-mod-jk/workers.properties.mycms-scorm
> JkLogFile       /var/log/apache2/mod_jk.log
> JkLogLevel      info

With "debug" you could see in the jk log file, if your JkEnvVars 
actually get forwarded. This is for version 1.2.26:

ajp_connection_tcp_send_message::jk_ajp_common.c (933):
01e0    2D 61 67 65 3D 30 00 A0 08 00 01 30 00 0A 00 03  -
-age=0.....0....

A0 08: Conten-Length is following
00 01: Length of Content-Length string is 1
30 00 (first byte in next line): value of Content Length is "0"
0A: request attribute follows
00 03: Name of request attribute has length 33

ajp_connection_tcp_send_message::jk_ajp_common.c (933):
01f0    66 6F 6F 00 00 03 62 61 72 00 FF 00 00 00 00 00  -
foo...bar.......

66 ... 6F 00: Name of request attribute is "foo"
00 03: value of request attribute has length 3
62 ... 72 00: value of request attribute is "bar"
FF: terminates the request

ajp_send_request::jk_ajp_common.c (1395):
(ajp13) request body to send 0 - request body to resend 0

> JkMount /my_player* icodeon

With version 1.2.26 you need to include your JkMount in the Virtual 
Hosts. JkEnvVars are merged between the global server and any vhost.

> # this is a hack to redirect this
> 
> <Location /my_player>
>        AuthName SINA
>        AuthType Basic
>        Auth_SINAuser on
>        Auth_SINAextras off
>        Auth_SINAexpire on
>        Auth_SINAproxys 1.1.1.1/255.255.255.255
>        ErrorDocument 401 /utils/auth/admin/
>        ErrorDocument 503 /utils/error/resolver/
>        SINA_Load_Max 100
>        ErrorDocument 416 /utils/load/admin/
> JkMount icodeon

JkMount and vhost see above.

>        <Limit GET POST PUT>
>                order deny,allow
>                allow from all
>                require valid-user
>        </Limit>
> </Location>
> 
> 
> 
> 
> file: /etc/libapache2-mod-jk/workers.properties.mycms-scorm
> # Define some properties
>  workers.apache_log=/var/log/tomcat
> #  worker.list=scorm,olat,icodeon
>  worker.list=icodeon
>  ps=/
> 
> # Set properties for worker1 (ajp13)
>  worker.icodeon.type=ajp13
> # FIXME use host name "scorm"?
> # worker.icodeon.host=scorm
>  worker.icodeon.host=debian
>  worker.icodeon.port=8009
>  worker.icodeon.connection_pool_size=10

Usually you want to get connection_pool_size determined automatically 
for Apache (default)

>  worker.icodeon.connection_pool_timeout=600
>  worker.icodeon.socket_keepalive=1
>  worker.icodeon.socket_timeout=60
> #  worker.icodeon.mount=/my_player*
> 
>>
>> There have been no changes to that code recently. I'm using TC 5.5.26 
>> in my test.
>>
> Hmm, I'm guessing I may need to find more recent versions (probably 
> back-ports)

Try updating mod_jk first. Then look at the debug log for a single 
request and check, if you can see the attribute forwarding there.

>>> I'm guessing I'm just looking for it in all the wrong places, so I'm 
>>> hoping someone can point me in the right direction.
>>
>> How do you retrieve the env var on the Tomcat side?
> public void doFilter(ServletRequest servletRequest, ServletResponse 
> servletResponse, FilterChain filterChain) throws IOException, 
> ServletException {
>        log.debug("\nAttributes ... begin.\n");
>        Enumeration attributeNames = servletRequest.getAttributeNames();
>        while(attributeNames.hasMoreElements()) {
>          String attributeName = (String) attributeNames.nextElement();
>          log.debug(attributeName + " " + 
> servletRequest.getAttribute(attributeName));
>        }
>        log.debug("\nAttributes ... end.\n");
> etc.
> }

Aha! This unfortunately doesn't work. The attributes coming in via the 
AJP protocol can be retrieved via request.getAttribute(), but are not 
(!) shown in getAttributeNames().

> Thanks for looking at this.
> I'm now suspecting I need a more recent version of Tomcat.
> Just in case though, your test code was run as a filter?  I've been 
> wondering if the filter saw something different from what the servlet sees?

Yes, as a filter.

> Regards,
> Keith

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message