You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by lu...@apache.org on 2003/07/21 21:06:35 UTC
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
luehe 2003/07/21 12:06:35
Modified: jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Log:
Added support for X-Powered-By response header, as defined by the
Servlet 2.4 and JSP 2.0 specs.
The Servlet 2.4 spec defines a special
X-Powered-By: Servlet/2.4
header, which containers may add to servlet-generated responses. This
is complemented by the JSP 2.0 spec, which defines a
X-Powered-By: JSP/2.0
header to be added (on an optional basis) to responses utilizing JSP
technology.
The goal of these headers is to aid in gathering statistical data
about the use of Servlet and JSP technology
Revision Changes Path
1.27 +12 -3 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
Index: JspServlet.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- JspServlet.java 25 Jun 2003 19:42:59 -0000 1.26
+++ JspServlet.java 21 Jul 2003 19:06:35 -0000 1.27
@@ -237,6 +237,15 @@
request.getParameter(name));
}
}
+
+ /*
+ * Add X-Powered-By header for JSP, if Catalina already added a
+ * corresponding header for servlets
+ */
+ if (response.containsHeader("X-Powered-By")) {
+ response.addHeader("X-Powered-By", "JSP/2.0");
+ }
+
serviceJspFile(request, response, jspUri, null, precompile);
} catch (RuntimeException e) {
throw e;
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Jan Luehe <Ja...@Sun.COM>.
> Arg, what a hack ;-) (and my definition is that we get into the servlet
> container; if it's an internal servlet, it seems good enough, and the
> page being served was served by a Servlet API 2.4 component)
> Come on, this is a stupid feature nobody but marketting cares about (and
> I'd say the said marketting folks should forget about it: Netcraft can
> count Java powered websites well enough already). I suppose the
> reasoning is that IIS/6.0 adds similar self agrandizing headers that it
> is .NET 1.1 powered, so we have to do the same. Lame.
> So the implementation of the feature has IMO to be as invisible as
> possible given its lack of usefulness.
OK, I was just trying to make sure we didn't miss anything. :)
Like I said (and which you confirmed), the DefaultServlet is a servlet,
so adding the response header (even) to static resources may not be too
far-fetched.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> one comment, though: By adding the xpoweredBy property to
> CoyoteConnector instead of Host/Context, we get the
>
> X-Powered-By: Servlet/2.4
>
> response header even for static resources. You could argue that this is
> OK, since static resources are handled by the DefaultServlet, but it may
> not be very intuitive.
>
> By defining the xpoweredBy property on Host/Context instead, and adding
> the response header in StandardWrapperValve (as in the original commit),
> we could suppress the header if the servlet being invoked is an instance
> of org.apache.catalina.servlets.DefaultServlet.
>
> What do you think?
Arg, what a hack ;-) (and my definition is that we get into the servlet
container; if it's an internal servlet, it seems good enough, and the
page being served was served by a Servlet API 2.4 component)
Come on, this is a stupid feature nobody but marketting cares about (and
I'd say the said marketting folks should forget about it: Netcraft can
count Java powered websites well enough already). I suppose the
reasoning is that IIS/6.0 adds similar self agrandizing headers that it
is .NET 1.1 powered, so we have to do the same. Lame.
So the implementation of the feature has IMO to be as invisible as
possible given its lack of usefulness.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy,
>> So I guess we have no choice but make it configurable (or not support
>> it at all, which I don't think is an option), but since you've agreed
>> that we should make this a configurable option (provided it is added
>> at the right places), this is no longer an issue.
>>
>> I just committed a revised impl of this (and reverted my previous
>> commit).
>
>
> Ok, cool :)
one comment, though: By adding the xpoweredBy property to
CoyoteConnector instead of Host/Context, we get the
X-Powered-By: Servlet/2.4
response header even for static resources. You could argue that this is
OK, since static resources are handled by the DefaultServlet, but it may
not be very intuitive.
By defining the xpoweredBy property on Host/Context instead, and adding
the response header in StandardWrapperValve (as in the original commit),
we could suppress the header if the servlet being invoked is an instance
of org.apache.catalina.servlets.DefaultServlet.
What do you think?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Remy Maucherat wrote:
>
> > BTW, I don't see why the spec saying that the header is optional implies
> > that the flag must be implemented as something optional. It merely means
> > that an implementation may ignore completely this feature.
>
> Actually, the Servlet spec is going to say this:
>
> Note that this header [X-Powered-By] is optional, but if the
> container supports this feature, it must be configurable to suppress this
> header.
>
> So I guess we have no choice but make it configurable (or not support
> it at all, which I don't think is an option), but since you've agreed
> that we should make this a configurable option (provided it is added
> at the right places), this is no longer an issue.
>
> I just committed a revised impl of this (and reverted my previous commit).
Ok, cool :)
Thanks,
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy Maucherat wrote:
> BTW, I don't see why the spec saying that the header is optional implies
> that the flag must be implemented as something optional. It merely means
> that an implementation may ignore completely this feature.
Actually, the Servlet spec is going to say this:
Note that this header [X-Powered-By] is optional, but if the
container supports this feature, it must be configurable to suppress this
header.
So I guess we have no choice but make it configurable (or not support
it at all, which I don't think is an option), but since you've agreed
that we should make this a configurable option (provided it is added
at the right places), this is no longer an issue.
I just committed a revised impl of this (and reverted my previous commit).
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Remy Maucherat <re...@apache.org>.
Tim Funk wrote:
> Could an alternative be to introduce a Valve which does the equivalent
> of mod_headers?
Well, I'm trying to reduce the stack trace length of the default
installation, so I don't think this is a good idea.
Jan's implementation was right IMO in the respect of where approximately
to insert the headers. I don't see how you could insert the JSP header
anywhere but in Jasper.
However, I'm against how it's configurable, because we'd have 400 flags
in Context and Host if every setting was like that one (and the place of
insertion should be refined).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Tim Funk <fu...@joedog.org>.
Could an alternative be to introduce a Valve which does the equivalent of
mod_headers?
-Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Posted by Martin Algesten <ma...@taglab.com>.
> You're using in your argument the most extreme example ;-)
> Here, it's only revealing the technology used. This is very little,
> and not any more revealing than a ".jsp" extension.
Well, at least it sort of illustrated my point (sledgehammer to crack a
nut) :) ...
Yes the header itself doesn't reveal much, but there's also inferred
knowledge such as "the existence of this header indicates possible TC >
5.0.x". But then you didn't mind having the config switch so why am I
sending this email?
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Remy Maucherat <re...@apache.org>.
Martin Algesten wrote:
> Remy, I don't agree with that at all. For security reasons you always
> want the option to reveal as little as possible about your system. By
> default httpd creates headers like:
>
> Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.9
> OpenSSL/0.9.6b
>
> Which for a paranoid sysadmin is far too much info to give away.
> Thankfully you can get rid of them in the httpd configurations (if you
> want another example look at bind and what that gives away by default).
> This is exactly the same thing, if the header is to be set in the
> response (I'm not commenting on the implementation details or wether it
> should be there), then there must be an option to turn it off.
You're using in your argument the most extreme example ;-)
Here, it's only revealing the technology used. This is very little, and
not any more revealing than a ".jsp" extension.
Anyway, I was ok with having that optional. However, I think the
implementation provided is bad.
As such, I confirm my -1 for the patch.
Instead, I believe it should be implemented in the following way:
- flag on the connector, with the Servlet header being set in the
CoyoteAdapter
- flag in the Jasper options (looking at the presence of another header,
and assuming it's the Servlet header is just ugly: how about other
implementations which embed Jasper ?); setting the flag only in
JspServlet can, however, be considered good enough (however, we should
IMO add the header addition in the generated source for consistent
results, since my original proposal of using HttpJspBase is not much
better than JspServlet)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServlet.java
Posted by Martin Algesten <ma...@taglab.com>.
On Tuesday, July 22, 2003, at 09:24 AM, Remy Maucherat wrote:
> Jan Luehe wrote:
>>> This is a pretty bad implementation IMO.
>>> What's the use of disabling this feature ?
>> The spec declares these headers as optional, which means Tomcat
>> should make them configurable. Some sites may prefer not to include
>> this information in their responses, for security reasons or >> whatever.
>
> IIS 6 has similar headers, and I believe do not have any option to
> hide them. This has no bandwidth savings or anything. It is not worth
> adding flags everywhere for that.
> If you really want to add a flag, add it on the connector, and set the
> header in the CoyoteAdapter. As for the JSP flag, it should be a
> Jasper option if you really want to have it optional, not based on a
> bad test (why does the presence of a X-Powered header indicate
> anything ?).
> BTW, I don't see why the spec saying that the header is optional
> implies that the flag must be implemented as something optional. It
> merely means that an implementation may ignore completely this > feature.
> I maintain my -1 (sorry for disliking your patches these days): adding
> configurability, down to flag addition in the core interfaces, to such
> a trivial feature is ridiculous (or we should have 300 flags in the
> Context interface, which we obviously don't want). Please revert your
> patch.
>
Remy, I don't agree with that at all. For security reasons you always
want the option to reveal as little as possible about your system. By
default httpd creates headers like:
Server: Apache/1.3.26 (Unix) mod_jk/1.1.0 DAV/1.0.3 mod_ssl/2.8.9
OpenSSL/0.9.6b
Which for a paranoid sysadmin is far too much info to give away.
Thankfully you can get rid of them in the httpd configurations (if you
want another example look at bind and what that gives away by default).
This is exactly the same thing, if the header is to be set in the
response (I'm not commenting on the implementation details or wether it
should be there), then there must be an option to turn it off.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
>> This is a pretty bad implementation IMO.
>> What's the use of disabling this feature ?
>
> The spec declares these headers as optional, which means Tomcat should
> make them configurable. Some sites may prefer not to include this
> information in their responses, for security reasons or whatever.
IIS 6 has similar headers, and I believe do not have any option to hide
them. This has no bandwidth savings or anything. It is not worth adding
flags everywhere for that.
If you really want to add a flag, add it on the connector, and set the
header in the CoyoteAdapter. As for the JSP flag, it should be a Jasper
option if you really want to have it optional, not based on a bad test
(why does the presence of a X-Powered header indicate anything ?).
BTW, I don't see why the spec saying that the header is optional implies
that the flag must be implemented as something optional. It merely means
that an implementation may ignore completely this feature.
I maintain my -1 (sorry for disliking your patches these days): adding
configurability, down to flag addition in the core interfaces, to such a
trivial feature is ridiculous (or we should have 300 flags in the
Context interface, which we obviously don't want). Please revert your patch.
>> -1 on the various flags and checks (just add the headers, without
>> flags and complexity). -0 if you can indicate a good reason for this.
>> Also, you shouldn't add the JSP 2.0 header in JspServlet. If you
>> precompile, it's not called. Put it in HttpJspBase.
>
> I had thought about adding the JSP 2.0 header in HttpJspBase, but then
> realized that the "extends" page directive allows you to specify the
> class that the generated servlet should extend, in which case
> HttpJspBase will be out of the picture. Do you have a better idea?
I forgot about that feature, but HttpJspBase seems less often out of the
picture than JspServlet. Did you try to get a stack trace from a
precompiled JSP (which will become the norm in 5.0.x) ? Or assume that a
compiled JSP is no longer a JSP, and then leave it in JspServlet.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Jan Luehe <Ja...@Sun.COM>.
>> +
>> + /*
>> + * Add X-Powered-By header for JSP, if Catalina already
>> added a
>> + * corresponding header for servlets
>> + */
>> + if (response.containsHeader("X-Powered-By")) {
>> + response.addHeader("X-Powered-By", "JSP/2.0");
>> + }
>> +
>
>
> This is a pretty bad implementation IMO.
> What's the use of disabling this feature ?
The spec declares these headers as optional, which means Tomcat should
make them configurable. Some sites may prefer not to include this
information in their responses, for security reasons or whatever.
> -1 on the various flags and checks (just add the headers, without flags
> and complexity). -0 if you can indicate a good reason for this.
> Also, you shouldn't add the JSP 2.0 header in JspServlet. If you
> precompile, it's not called. Put it in HttpJspBase.
I had thought about adding the JSP 2.0 header in HttpJspBase, but then
realized that the "extends" page directive allows you to specify the
class that the generated servlet should extend, in which case
HttpJspBase will be out of the picture. Do you have a better idea?
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet
JspServlet.java
Posted by Remy Maucherat <re...@apache.org>.
luehe@apache.org wrote:
> luehe 2003/07/21 12:06:35
>
> Modified: jasper2/src/share/org/apache/jasper/servlet JspServlet.java
> Log:
> Added support for X-Powered-By response header, as defined by the
> Servlet 2.4 and JSP 2.0 specs.
>
> The Servlet 2.4 spec defines a special
>
> X-Powered-By: Servlet/2.4
>
> header, which containers may add to servlet-generated responses. This
> is complemented by the JSP 2.0 spec, which defines a
>
> X-Powered-By: JSP/2.0
>
> header to be added (on an optional basis) to responses utilizing JSP
> technology.
>
> The goal of these headers is to aid in gathering statistical data
> about the use of Servlet and JSP technology
> +
> + /*
> + * Add X-Powered-By header for JSP, if Catalina already added a
> + * corresponding header for servlets
> + */
> + if (response.containsHeader("X-Powered-By")) {
> + response.addHeader("X-Powered-By", "JSP/2.0");
> + }
> +
This is a pretty bad implementation IMO.
What's the use of disabling this feature ?
-1 on the various flags and checks (just add the headers, without flags
and complexity). -0 if you can indicate a good reason for this.
Also, you shouldn't add the JSP 2.0 header in JspServlet. If you
precompile, it's not called. Put it in HttpJspBase.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org