Hi Andre, see below. You are not going to hear me slapping my face, but definitely doing "ahhhh!" :-)
Cheers Martin ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de ----- Original Message ---- > From: André Warnier <a...@ice-sa.com> > To: Tomcat Users List <users@tomcat.apache.org> > Sent: Fri, May 27, 2011 6:01:28 PM > Subject: Re: Weird problerm accessing request headers from tomcat > > Hi. > > I believe that you are making the often-made confusion between "environment >values" (or variables), and HTTP headers content. > In particular, here : > seems you are right. > >> Apache1 inserts the following variables into the requests it forwards to >Apache1 (I suppose you meant Apache2 here) > > No. It does not do that. It adds some HTTP headers. This is different, see >below. > > . Apache1 (I suppose you meant Apache2 here) can see them, I have checked > that >using cgi-bin/printenv (some > >> values anonymized): > >> > >> HTTP_X_FORWARDED_FOR="aa.bb.cc.dd" > >> HTTP_X_FORWARDED_HOST="xxx.yyy.net" > >> HTTP_X_FORWARDED_PORT="443" > >> HTTP_X_FORWARDED_PROTOCOL="https" > >> HTTP_X_FORWARDED_SERVER="aaa.bbb.ccc" > >> > Your check does not show that at all. It shows something that is just >confusing enough to get you confused as to what you are seeing. ;-) > > But you have excuses for your confusion, because the Apache documentation >itself is very confusing as to "environment variables". > Indeed, the documentation leaves this pretty diffuse. > What the cgi-bin script sees, are indeed "environment values". > These are set by the Apache process (Apache2), just before it executes the >cgi-bin script. So the cgi-bin script sees them in its environment when it >runs. > (like with $ENV{'HTTP_X_FORWARDED_PORT'}) > > But there is no one-to-one relationship between what Apache finds in HTTP >request headers, and the environment values which it sets for the cgi-bin >scripts that it runs. > Apache does "convert" some of the request HTTP header values into cgi-bin >environment variables, but : > - the name of the environment variable may be different from the > corresponding >HTTP header label (you see this yourself above : a HTTP header named >"X-forwarded-for:" has been passed to the cgi-bin script as the environment >value named "HTTP_X_FORWARDED_FOR") > - not all HTTP headers are converted and passed that way > - some environment values passed to the cgi-bin script are not, and never >were, HTTP headers of the request (for example, the cgi-bin environment >values >"QUERY_STRING", or "SCRIPT_FILENAME") > Ok, that definitely explains what I am seeing. > On the other hand : > > When a HTTP proxy server forwards a HTTP request to another HTTP server via >the HTTP protocol, it forwards *all* the request headers and request content >to >this other server, as a HTTP request (otherwise, it would not be a valid HTTP >proxy server). But it cannot forward "environment values", because there is >no >defined way of doing this over the HTTP protocol. (*) > > > But now I see your second post, and your problem is in fact much simpler. > > By doing this : > h:outputText style="font: bold 14px sans-serif;" > > value="X_FORWARDED_HOST: #{header['X_FORWARDED_HOST']}" /> > > what you are actually trying to retrieve, is the content of the HTTP request > >header > "X_FORWARDED_HOST:" (I guess), but this HTTP header does not exist in the >request. > What you are giving as a HTTP header name, is actually what the cgi-bin >environment value name was for your cgi-bin. > Which, as I try to explain at long length above, is not the same thing. > > So you get back a null, and you think that the header was not there. > But it is there, only under its real HTTP header name. > Try something like > value="X_FORWARDED_HOST: #{header['X-Forwarded-for']}" />" > instead. > Yup, using "X-Forewarded-Host" works as expected. Thanks a big lot. > (Noise of self-slap on face ?). > As I said above: no self slapping. Just amazement on how much there is still to learn after all these years :-) > > > (*) However, when the proxy protocol used is AJP (as it is between Apache > and >Tomcat when using the mod_jk connector, or the mod_proxy_ajp connector), >/then/ >some additional values /can/ be passed along with the request (because the >AJP >protocol allows that). On the Tomcat side, these then appear as "request >attributes" which the webapp can retrieve (via request.getAttribute(name)), >but >not as "environment values" of the Tomcat process for example. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
