tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Why are some header values hidden in HttpProcessor.java ?
Date Tue, 12 Sep 2000 20:13:12 GMT
Bernd Eilers wrote:

> Hi there !
>
> I'm not sure if this is a bug or a feature, so a Question to the
> HttpProcessor.java in Catalina
>
> Why is it that HttpProcessor.java hides some informations send in the
> HTTP request to the servlet API and as such makes it impossible for a
> servlet to reconstruct the original Request ?
>
> Example for why this is at least a undisirable "feature" is the following
> Servlet API use:
>
> Implement a servlet that runs in a webserver before the firewall and
> forwards the request (probably a little bit modified) to annother
> webserver in the intranet.
>
> More detailed questions:
>
> What is the reason to exclude the "authorisation" header by the following
> code ?
>
> if (!match.equals("authorisation"))
>         request.addHeader(name,value);
>

The concern in this case was that the user credentials might get
inadvertently exposed -- for example, if you were running SnoopServlet under
the protection of a security constraint.  The philosophy behind this is that
container managed security should be totally transparent to applications.

For your particular scenario, you can find out the username
(request.getRemoteUser()) -- you just cannot find the password.  However, it
does make your use case pretty difficult to implement.  What would you think
about a configurable parameter that defaults to suppressing this header, but
allows you to change this if you need it?

>
> And what is the reason for excluding the jsession Session ID Cookie from
> the list of cookies by using this construct ?
>
> if
> (cookies[i].getName().equals(org.apache.tomcat.connector.Constants.Sessi
> onCookie))
> // ...
> else
> request.addCookie(cookies[i]);
>

A similar philosophical reason -- container session management should also be
transparent.  For your "proxy" use case, it seems like a configurable option
for this would also solve the problem.

>
> Bernd
>

Craig

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat



Mime
View raw message