You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bernd Eilers <be...@stardivision.de> on 2000/09/12 14:34:52 UTC
Why are some header values hidden in HttpProcessor.java ?
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);
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]);
Bernd
Re: Why are some header values hidden in HttpProcessor.java ?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Bernd Eilers wrote:
>
> Summing everthing up so far:
>
> I think the best would be to have a configurable option as you suggested,
> but the default should be not to suppress this header and not to suppress
> this cookie because the DEFAULT for tomcat should be to be compliant to
> the servlet api specification.
>
I can buy into your reasoning. The change to make the session ID cookie visible
actually got made a few days ago (for Tomcat 4.0), and I'm about to check in the
change to make the "Authorization" header visible.
>
> 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
Re: Why are some header values hidden in HttpProcessor.java ?
Posted by Bernd Eilers <be...@stardivision.de>.
ReHi !
> > [...]
> > 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.
Well I do unterstand the intention behind that, but ...
> 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?
Well, if it was just for that special use case of mine I would say a
configurable parameter is OK and i don't care about what it's default is.
On the other hand i don't really get the argument of inadvertently
exposed credentials.
Either a Authentication mechism is secure or it is not secure.
HTTP/1.1 defines some secure and some lazy secure or insecure
authentication mechanisms.
If access to the Authorisation header reveals security relevant
information this can only be the case if an insecure authentication
mechanism is used anyway ( eg. basic authentication ).
I can see no valid reason to make the endpoints of a client server
connection more secure than what already is revealed over the network
connection. Why should the software running on the server get less
information than the attacking man in the middle. If it can be
/sbin/snoop (ed) on /dev/ether why should a SnoopServlet not see it ?
On the other hand the documentation for getHeaderNames() in the servlet
API is
Returns an enumeration of all the header names this request contains
So if it really is useful for some cases to have that configurable
parameter that allows the container to turn that all to most ( which it
don't really think it is ) this should be clearified in the servlet ( 2.3
) spec and servlet programs should have a some hasAllHeaderNames() kind
of function available.
> >
> > 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.
If something is transparent doesn't that mean than you can look through
it and see everything on the other site ;-)
> For your "proxy" use case, it seems like a configurable option
> for this would also solve the problem.
Here my argument against this is also similar as for the header names,
The documentation for getCookies() in the servlet API at least for now is
Returns an array containing all of the Cookie objects the client sent
with this request.
Unless this is not identified as an errata in the Java servlet
specification it shouldn't be implemented differently to this
documentation.
Summing everthing up so far:
I think the best would be to have a configurable option as you suggested,
but the default should be not to suppress this header and not to suppress
this cookie because the DEFAULT for tomcat should be to be compliant to
the servlet api specification.
> 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
Bernd
Re: Why are some header values hidden in HttpProcessor.java ?
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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