Re: Cookie parsing and upcoming updates to RFC6265

[Tim Funk]

How about  missingEqualsCookie="allow | ignore"?

By using [allow | ignore] instead of yes/no, it opens the door to
additional behaviors. (such as reject which triggers a http error)

-Tim

On Fri, Aug 16, 2024 at 4:33 AM Mark Thomas  wrote:

> On 14/08/2024 19:12, Konstantin Kolinko wrote:
>
> 
>
> I'm going to start working on this "noEqualsCookie" option. Suggestions
> for a better name still welcome.
>
>

Re: [VOTE] Release Apache Tomcat 9.0.93

[Tim Funk]

On Fri, Aug 2, 2024 at 7:03 PM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.93 release is now available for voting.
>
> The proposed 9.0.93 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.93
>
>
-Tim

Re: [VOTE] Release Apache Tomcat 9.0.92

[Tim Funk]

+1 (see below)

On Mon, Jul 29, 2024 at 11:32 PM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.92 release is now available for voting.
> 
> The proposed 9.0.92 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.92
>
>

Re: [PROPOSAL] Enable SecureLifecycleListener by default

[Tim Funk]

Somewhat related and tangential to the other conversations 

Is it worth introducing a system property like
"-Dtomcat.security.harden=true". (Personally not sold yet on the idea)

Then when set to true ...
- It can go nuts with additional SecureLifecycleListener checks
- It can disable all OOTB webapps (ROOT/docs/etc) (Which then requires a
new filter on those webapps)
- Other hardening checks (minimal error pages, server headers, ...)

So from a security perspective, it's trivial to enable. But from a
developer getting started perspective, the docs,etc are easy to see?


-Tim

On Thu, Jun 6, 2024 at 10:46 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I'd like to remove the  around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 9.0.87

[Tim Funk]

No issues noticed via internal testing.

-Tim

On Mon, Mar 11, 2024 at 7:10 AM Rémy Maucherat  wrote:

>
> The proposed 9.0.87 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.87
>
>

Re: [VOTE] Release Apache Tomcat 9.0.78

[Tim Funk]

+1

-Tim

On Tue, Jul 4, 2023 at 9:28 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.78 release is now available for voting.
>
> The notable changes compared to 9.0.76 are:
> 
> The proposed 9.0.78 release is:
> [ ] -1, Broken - do not release
> [ X ] +1, Stable - go ahead and release as 9.0.78
>
>
>

Re: [VOTE] Release Apache Tomcat 9.0.75

[Tim Funk]

On Thu, May 4, 2023 at 10:20 AM Rémy Maucherat  wrote:

> The proposed Apache Tomcat 9.0.75 release is now available for voting.
>
> The proposed 9.0.75 release is:
> [ ] -1, Broken - do not release
> [X] +1, Stable - go ahead and release as 9.0.75
>
>

Re: [VOTE] Release Apache Tomcat 9.0.74

[Tim Funk]

On Thu, Apr 13, 2023 at 4:43 AM Rémy Maucherat  wrote:

>
> The proposed 9.0.74 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.74
>
>
>

Re: Tomcat 11 - minimum Java version

[Tim Funk]

On Wed, Jan 11, 2023 at 6:44 AM Mark Thomas  wrote:

> On 11/01/2023 11:38, Rémy Maucherat wrote:
> > On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas  wrote:
>
> 
>
> Just playing devils advocate for a second, is Java 21 going to be too
> big a leap for the majority of users? Might the Tomcat community be
> better with Java 17 as the minimum version for Tomcat 11?
>
>
>From a sysadmin and app developer perspective  I have a feeling Tomcat
9 will linger for a very long time due to the javax -> jakarta migration.
To jump from 9-->11 requires that migration. So additionally requiring Java
21 doesn't seem like a horrible barrier.

-Tim

Re: Do we want to increase the default value of maxHttpHeaderSize?

[Tim Funk]

Doubling might be convenient.

Let's say a URI is between 4000 and 8000. There is a good chance there
could be a Referer header of equal size too. Which can easily push you over
the 8192 default. (and that doesn't even include the ever increasing
explosion in cookie size)

-Tim

On Mon, Aug 1, 2022 at 8:11 AM Mark Thomas  wrote:

> Hi all,
>
> RFC 9110 recommends supporting URIs of at least 8000 octets in size.
>
> Currently, all versions of Tomcat limit the request line and headers to
> 8192 octets by default.
>
> The current limit is, technically, in compliance with RFC 9110 but with
> a ~8000 octet URI there isn't much room left for any HTTP headers. Given
> the recommendation of RFC 9110 do we want to increase this default?
>
> I am currently leaning towards leaving the default as is unless we have
> any evidence that the majority of users are finding they need to
> increase it.
>
> Thoughts?
>

Re: Any interest in a read-only JMX role?

[Tim Funk]

Doing a quick dive and restricting invoke, get, set, query to their own
roles looks "easy" since they have their if() checks.(Easier to lock down
than I recalled)

As for further locking down get() - I guess one could add an init() param
to the servlet called get-approve-list which can be a white space, comma,
(or whatever) separator of regexes to approve in. (And the absence of the
parameter allows .+)

EXAMPLE web.xml

   get-approve-list  
  
java.lang:type=Memory
^java.lang:.+
  


Replacement to around line 112 of existing JMXProxy
qry = request.getParameter("get");
if (qry != null) {
boolean matches = false;
for (String regex:getRestrictions ) {
matches = matches || qry.matches(regex);
}
if (!matches) {
throw new Error403(); /* I made this up */
}

String name = request.getParameter("att");
getAttribute(writer, qry, name, request.getParameter("key"));
return;
}

As for status  If you strike the the active requests from
"/manager/status?XML=true" (Which can leak session info) - You have a
pretty good status monitor (even though its XML)

-Tim

On Mon, Jun 13, 2022 at 2:29 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

>
> I think the JMXProxyServlet is better than JMX itself for a number of
> reasons. Though platform JMX access has improved in the last few
> versions, the fact is that Tomcat's ability to provide access to JMX
> (through HTTP) is far more flexible and secure than the heavy-handed JMX
> capabilities provided by the platform.
>
> I would be strongly against deprecating the JMXProxyServlet for that
> reason moving forward.
>
>

Re: Any interest in a read-only JMX role?

[Tim Funk]

I think JMXProxy should be eventually deprecated. It's "too powerful" for
what it can do. At the time of creation - it was a neat idea that was
powerful. But if I had to imagine if we would create such a servlet today,
security alarms would be loudly clanging.

I think a read only option would help lock things down for those who prefer
only reading JMX stats. So in that sense it's an extra layer of support.
But conversely, I also think it's a false sense of security.

-Tim

On Mon, Jun 13, 2022 at 12:32 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I've been thinking about the possibility of making a read-only JMX role
> available for the existing manager-jmx capability.
>
> The idea would be that this role would only be able to make "get"
> requests (that is, a JMX-get operation, not HTTP-GET). No "set" or
> "invoke" operations would be allowed.
>
> The manager-jmx role has quite a bit of power, and is typically used
> only for monitoring where being able to modify the server is not
> necessary. If manager-jmx is being used "only" for monitoring, then
> opening-up the system for potential reconfiguration by the monitoring
> user is a potential attack vector.
>
> I don't think the level-of-effort would be significant: simply require
> "manager-jmx" for set/invoke operations and require either manager-jmx
> or manager-jmx-read-only (or something similar) for get operations.
>
>

Re: [VOTE] Release Apache Tomcat 9.0.62

[Tim Funk]

On Thu, Mar 31, 2022 at 10:56 AM Rémy Maucherat  wrote:

>
> The proposed 9.0.62 release is:
> [ ] Broken - do not release
> [X] Stable - go ahead and release as 9.0.62 (stable)
>
>

FAQ Entry added for log4j2 CVE-2021-44228

[Tim Funk]

If I've mis-identified anything - let me know. We could point people to
this if we continue to get questions:

https://cwiki.apache.org/confluence/display/TOMCAT/Security#Security-Q13

-Tim

Re: Request for documentation improvement: changelog UI

[Tim Funk]

 I think this will do it ...
The CSS

.sticky {
position: fixed;
top: 0;
right: 20px;
left: 210px;
margin-top: 0;
}


And you'll need an event listener ...
document.addEventListener( 'scroll',
  function(){
var h3s = document.getElementById('content').getElementsByTagName('h3')
for (var i=0;i h3.offsetTop) {
h3.setAttribute('data-original-offsettop', h3.offsetTop)
h3.classList.add("sticky");
  }
}
  }
)

I ran the above on the existing changelog and it seemed to work OK.

-Tim

On Wed, Sep 9, 2020 at 9:25 AM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> Could someone better at CSS look into this for me?
>
> I sometimes find myself searching the changelog for some string e.g.
> "keystore". I generally do that by loading-up the changelog in my
> browser and using the browser's "Find" feature to search the text. (Duh)
> .
>
> The changelog for each version, however, usually stretches to a few
> screen-heights and it's often not possible to see the version number
> where a particular changelog item is included. I often have to find
> something, then scroll "up" to see the version number.
>
> This isn't a big deal when locating something specific: it generally
> occurs once (like a bug id) and then you go look at the version number
> and you are done.
>
> But when trying to find something that happened between versions X and
> Y, there is a great deal of scrolling, searching, re-scrolling,
> re-searching, etc. which may be avoided if the following is possible.
> (And I'm sure it is).
>
> What I'd like is for the  headings on the changelog pages to
> "stick" to the top of the screen as they are scrolled. So, for
> example, if you load the changelog for Tomcat 9, you'll see at the
> very top of the page there is the standard Tomcat documentation header
> ("Tomcat", current version number, latest release-date), then the
> "Changelog" header, then the first  which is currently "Tomcat
> 9.0.37 (markt)".
>
> As you scroll, the "Tomcat 9.0.37 (markt)" eventually scrolls up off
> the top of the visible page (as web pages generally do). Instead, when
> that heading gets to the top of the page, I'd like it to "stick" there
> until scrolling replaces it with the next  in the order, which is
> currently "Tomcat 9.0.36 (markt)".
>
> This would keep the version number where fixes/improvements have been
> made at the top of the screen during any searching activity and make
> it much easier to hunt for certain kinds of fixes.
>
> Is anyone willing to look into implementing the above?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9Y17oACgkQHPApP6U8
> pFjN0xAAhfFd0Yl69XF38f5tSYtMQMQcDNIOywVDXCIBWnYaSIUPWvzFAPeq0uv/
> t7Hvc2MlQ+QlKfu3aiq0PEOpCRy2QEQ9EDDGEonxRPvhQrkhUIDlkuGpTvYrS1XA
> RF7XSUuV+g9eVyFeh1KQEQP1BCAKXjxXLNl51v6xHP+FMiySAtAgCF7U3DVbB/fw
> rXILy6/wgSjdWyQkcC+yZ/5OHxp9R3s8E80MT0Kdwp7oTtdlCq0bFOdcmqQZqC92
> 9658bGQhllYfF7eqMeWRVO8TdlIyAI0RFJU8gVlt9IGWy5OHzc6QB853O4ejA8G0
> xrjeKVwzWYBNUImkfxxqXoOSdK8/rKK/zEZtBi7GuHeYLiqn8JBvFS4NZGp0rMNY
> xWYAf0Nhql+y+gDDbpk10CplptNePCUXjF6fSX7IPSsgpBwyjDbGl671s08DOM83
> TJq5NwwjJS37kPmHY7g0DRdhtn0dKf45H97Kdpqm/BEp8Vua63eEtK8WFFXmOVBd
> hhEADE8ccQg639U5jxshI9F3wxnChNcfOSKDcdxmCU0Rgfslq3ujgqzZ2sqCHNVP
> 9SwJiolW76PUFLG02LasM1FYzPSYv85a/0DH5lPGUMpB3EvczCnu5FWagsTS3fu5
> 8JCHz7Eyo1SrijeMtE/NgSV0LpKbuGjh8v+BUBODiW+jD8vfxxI=
> =4+RB
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Finally getting around to switching to Git

[Tim Funk]

Or maybe confluence cwiki?

-Tim

On Fri, Apr 26, 2019 at 8:26 AM Coty Sutherland  wrote:

> On Fri, Apr 26, 2019 at 3:13 AM Mark Thomas  wrote:
> ...
> > I'd suggest sharing Git experiences is a topic of conversation at the
> > Hackathon.
> >
>
> +1, except I won't be there :( Is that something we can have someone take
> notes on and send to the dev list after?
>
>

Re: Wiki migration

[Tim Funk]

Thanks! I've done the following
- Created a page called "Parent page for Trash"
- Moved all user pages and many spam pages under that page (drag/drop a lot
faster than clicking page then choose delete from options)
- Put most FAQ pages under FAQ parent and removed FAQ from most page names
- Did basic formatting cleanup and very minimal content removal for
inaccurate information
- Moved FAQ out of the "Migrated Content folder"


Next todo's
- Either create a top level how to and move more pages under it. Or put
them under a HowTo in the FAQ hierarchy. This should cleanup quite a few
pages out of the Migrated Content folder
- Go back trough the FAQs and decide what to do with many of the dated
tomcat 5/6 references.
- Determine how to fix many of the broken mailing list links.
- Try to determine where any remaining Migrated Content pages go.





On Sun, Mar 17, 2019 at 4:12 PM Mark Thomas  wrote:

> It was a permission issue. I've just fixed that.
>
> Mark
>
>
> On 17/03/2019 20:02, Tim Funk wrote:
> > Hmm ...
> >
> > Either I don't have permissions to make edits, or I need read a
> tutorial. I
> > was going to delete some obvious spam pages which were migrated and then
> > start moving other questionable pages to a sandbox to be debated later.
> >
> > I signed up via my apache email address.
> >
> > -Tim
> >
>

Re: Wiki migration

[Tim Funk]

Hmm ...

Either I don't have permissions to make edits, or I need read a tutorial. I
was going to delete some obvious spam pages which were migrated and then
start moving other questionable pages to a sandbox to be debated later.

I signed up via my apache email address.

-Tim

Re: Wiki migration

[Tim Funk]

Thanks Mark.

Through the rest of the month, I can try to set aside some time to take a
look at fixing the pages Confluence.

-Tim


On Fri, Mar 15, 2019 at 7:32 PM Mark Thomas  wrote:

> On 15/03/2019 18:32, Mark Thomas wrote:
> > On 15/03/2019 18:05, Konstantin Kolinko wrote:
> >> пт, 15 мар. 2019 г. в 20:07, Mark Thomas :
> ...
> The migration is complete.
>
> We have a couple of options:
>
> 1. Make moin read-only at this point and start tidying up the pages that
> were migrated Confluence
>
> 2. Leave moin as, treat this migration as a test. Review what was
> migrated and do the real migration at a later point.
>
> 3. Something else.
> ...
>
>
>

Re: [VOTE] Migrate to git

[Tim Funk]

[X] +1 Go ahead with the migration

A huge thanks to all the time, thought and planning to make this possible.

-Tim

Re: [VOTE] Migrate to git

[Tim Funk]

Sorry for the double email (sending via my apache account so its official)

[X] +1 Go ahead with the migration


-Tim
>

Re: Quick review of outline for Tomcat security presentation?

[Tim Funk]

Nice ...

Some possible adds ..
- Keep your java up to date (companion point to OS update)
- Link to OWASP (whole talk to itself)
- IP Filtering ... Consider a WAF
- IP Filtering ... Where possible - Block all outbound connections
- Maybe Lockout realm worth a quick mention?
- IIRC: Clustering has assumptions on the security of the network


-Tim

On Mon, Feb 11, 2019 at 2:53 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> New and improved! With a link to the outline!
>
> https://people.apache.org/~schultz/Apache%20RoadShow%20DC%202019/Locking
> - -Down%20Apache%20Tomcat_outline.pdf
>
>

Re: New design for the Tomcat website

[Tim Funk]

I noticed that too ... but since the "integrity" attribute is present, it
doesn't seem as much a concern.

I did notice a few inline "p style="text-align: center;" which seems to be
better suited to a class element. But since they seem to be downloads -
Keeping them left aligned would work too.  Or possibly adding "btn
btn-primary" for the download links (but it that is done, the change log
links might look out of place, but class="btn btn-secondary" might work for
the change log links too)

-Tim

On Thu, Jan 3, 2019 at 6:13 AM Rainer Jung  wrote:

> I like the modern design but there are at least 5 objects loaded from 5
> non-apache.org-domains (jquery, cloudflare, bootstrapcdn, googleapis,
> gstatic). Personally I would prefer if we wouldn't trigger requests to
> non-apache.org-domains.
>
>

Re: Removal of author tags in trunk

[Tim Funk]

Yes - Feel free to remove my name.

@author Tim Funk

-Tim

Re: svn commit: r1529816 - in /tomcat/trunk: conf/catalina.properties java/org/apache/catalina/startup/Bootstrap.java test/org/apache/catalina/startup/TestBootstrap.java webapps/docs/changelog.xml

[Tim Funk]

Will this work with [insert "poorly", 'very'" poorly name'd 'directory'
here] ?

-Tim


On Mon, Oct 7, 2013 at 6:55 AM,  wrote:

> Author: markt
> Date: Mon Oct  7 10:55:18 2013
> New Revision: 1529816
>
> URL: http://svn.apache.org/r1529816
> Log:
> Partial fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=55620
> Handle the case of a comma in $CATALINA_HOME or $CATALINA_BASE
>
> Added:
> tomcat/trunk/test/org/apache/catalina/startup/TestBootstrap.java
> (with props)
> Modified:
> tomcat/trunk/conf/catalina.properties
> tomcat/trunk/java/org/apache/catalina/startup/Bootstrap.java
> tomcat/trunk/webapps/docs/changelog.xml
>
> Modified: tomcat/trunk/conf/catalina.properties
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/conf/catalina.properties?rev=1529816&r1=1529815&r2=1529816&view=diff
>
> ==
> --- tomcat/trunk/conf/catalina.properties (original)
> +++ tomcat/trunk/conf/catalina.properties Mon Oct  7 10:55:18 2013
> @@ -44,7 +44,10 @@ package.definition=sun.,java.,org.apache
>  # "foo/*.jar": Add all the JARs of the specified folder as class
>  #  repositories
>  # "foo/bar.jar": Add bar.jar as a class repository
>
> -common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
> +#
> +# Note: Values are enclosed in double quotes ("...") in case either the
> +#   ${catalina.base} path or the ${catalina.home} path contains a
> comma.
>
> +common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar"
>
>

Re: Code style rules: Line length

[Tim Funk]

My opinion only (since I've been pretty inactive lately ... only enough
time to lurk)

I'm a big fan of long method/class names and 80 character width drives me
nuts - unless your IDE is a phone - 80 is not very wide.

100 many times is just enough extra space to limit a lot of wrapping.
(preferred soft limit)

120 is pretty wide and with enough side bars open in your IDE - this could
get annoying.




On Thu, Aug 8, 2013 at 1:50 PM, Mark Thomas  wrote:

> Currently, Tomcat has an 'guide' of a maximum of 80 characters for line
> length. It has been a while since we reviewed this and as we are looking
> at style rules...
>
> As a starting point what do folks think of the following options:
>
> Line length:
>  80 - the current
> 100 -
> 120 -
>
> Strictness
> Informal - the current
> Enforce  - Use checkstyle to enforce whatever limit is chosen
>
>
> Pros for longer lines:
> - code easier to read
>
> Cons
> - diffs may wrap in mail clients
> - harder to work with code in a pure text interface (particularly if
> that interface is limited in width to 80 chars)
>
>
> Comment
> - With increasing screen resolution I expect IDEs to manage widths upto
> 120 or possibly even more
> - Few (any?) folks will ever need to work in a pure text UI where the
> line length is limited
> - My only concern is readability of diffs
>
> I have no strong preference on line length but if we do opt for a longer
> length I'd like to see checkstyle enforce the limit.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [RESULT][VOTE] Tighten up wiki security to reduce spam

[Tim Funk]

My wiki id is TimFunk

-Tim


On Wed, Apr 24, 2013 at 4:38 PM, Konstantin Kolinko
wrote:

> 2013/4/25 Mark Thomas :
> > On 24/04/2013 21:23, Mark Thomas wrote:
> >> +1 (binding): markt, funkman, rjung, olamy, kkolinko (with regret)
> >> +1:   Ognjen Blagojevic, violetagg, Chuck
> >>
> >> I'll ask infra to make the necessary changes.
> >
> > Done:
> >
> > https://issues.apache.org/jira/browse/INFRA-6196
> >
> > Based on the most recent anti-spam efforts I requested the Konstantin,
> > Chuck and I be added to the admin group. We can add other community
> > members on request (same for contributors). The first task will be to
> > add the current committers and any other regular contributors to the
> > contributors group.
> >
>
>
>

Re: [VOTE] Tighten up wiki security to reduce spam

[Tim Funk]

> [X] +1 Make it so

I'm surprised not to see more discussion ... but it could be due to the
word spam in the subject line. So many folks (maybe including me) aren't
seeing any of the replies. (or possibly the original vote request so they
are unable to reply/vote)

-Tim



On Fri, Apr 19, 2013 at 10:49 AM, Mark Thomas  wrote:

> On 19/04/2013 15:49, Mark Thomas wrote:
> > Should the changes described in [1] be applied to the Tomcat wiki?
> > [X] +1 Make it so
> > [ ]  0 No opinion
> > [ ] -1 I object to this proposed change because...
>
> My vote for the record.
>
> Mark
>
> > [1]
> >
> http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Wiki (was: Update of "LocalBadContent")

[Tim Funk]

+1 for the lock down. [with sadness] If someone would like to add content
it can be done via bug report. [Component  =  Wiki? ] Then if a few are
filed by the same person escalate their access as trusted. I can try to
keep an eye on these types of bugs flowing through.

+1 To removing the powered by page too.

Otherwise - you guys have been awesome in keeping the spam out.

-Tim

On Wed, Mar 20, 2013 at 8:36 AM, Konstantin Kolinko
wrote:

> 2013/3/19 Mark Thomas :
> > On 18/03/2013 21:46, Apache Wiki wrote:
>
> Previous discussions:
> [2] (Jun 2011) http://tomcat.markmail.org/thread/nndyb3elaee6nduv
> [3] (Dec 2011) http://tomcat.markmail.org/thread/llawwzb4jxgwbt6z
>
> +0. It is a bit of a pity, but I would not oppose the change.
>
> I'd say that if we go this tight security way, then I think we should
> remove most of "Powered by" page (maybe all besides articles) and do
> not bother maintaining it.
>
>

Re: Using comments.apache.org for our live docs

[Tim Funk]

Nice. +1

-Tim

On Wed, Nov 7, 2012 at 5:31 PM, Rainer Jung  wrote:
 


> I prepared a simple demo at:
>
> http://people.apache.org/~**rjung/tomcat-docs-comments/**tomcat-8.0-docs/
>
> It would be nice if you would have a look and we would discuss, whether we
> find it useful or not. The patch for build.xml and the xsl that I applied
> to build the comment enabled docs can be found at
>
> http://people.apache.org/~**rjung/patches/tc-trunk-**comments.patch
>
>

Re: Proposal: use tomcat-version-number in server.xml element?

[Tim Funk]

Sounds like a job for a LifeCycleListener. (and therefore easy to backport)

-Tim

Re: question on IP for VirtualContext

[Tim Funk]

IIRC: this came into existence via
https://issues.apache.org/bugzilla/show_bug.cgi?id=41260 - it was donated
by the original contributor and the patch provided had the ASL license.

Borrowing features is OK, code is not unless the code is granted. It may be
as simple as contacting  the original author for another code grant and
posting that to bugzilla to keep everything as transparent as possible.

-Tim

Re: [RFC] Netmask-based filter and valve

[Tim Funk]

Looks ok ... a few comments.

RemoteCIDRFilter (most of the below apply to the valve too)

setAllow = If nothing passed  - This should clear allow
setAllow = If a bad "allow" is passed - throw exception. I'd think throwing
an IllegalArgumentException is OK so no catch is needed. Depending on when
this is called ... throwing an UnavailableException might cause enough
disruption to disable the webapp too. (depending on the exception
propagation)

setAllow,setDeny - Should all the netmasks be verified before before
internal allow/deny is updated? If can be possible that only some masks are
applied before exception is thrown. Which causes a partial mask to be
working. Of course ... if the exception is thrown and the webapp is
disabled... this might not be an issue.

setAllow,setDeny - call clear() before adding new values. With
embdedding,JMX etc - these can be called multiple times with different
values post startup.

getAllow/getDeny - Needs tweaked since most would assume the output of
getAllow() can be used to do setAllow(). By using List.toString() - [] would
be added.

-Tim


On Mon, Oct 10, 2011 at 2:22 PM, Francis Galiegue wrote:

> Hello list,
>
> Frustrated by the limitations of existing
> Remote{Addr,Host}{Filter,Valve}, I have coded an implementation of a
> Filter and Valve doing netmask-based matching. These valves can also
> do IP-based matching (just don't specify a netmask).
>
> Having quite some difficulties writing unit tests for now, I have
> instead tried it in "real life" situations, that is using both in a
> temporary install on both IPv4 and IPv6. They both work.
>
> But I need help. Not only with writing unit tests, which for now only
> exist for the base NetMask class, but also for error handling (what
> should be done when an illegal netmask is supplied, etc).
>
> You can see the whole patch here:
>
>
> https://github.com/fge/tomcat70/commit/79e276d13ba804d0ae06c75592d0364cb2110285
>
>
>

Re: svn commit: r1179274 - /tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java

[Tim Funk]

I'm a little confused. On a quick glance of the method ... it appears the
method setProperty should be returning true if it did something, and false
if not. This would mean the cast is not needed (actually wrong). The fact
that the method did NOT throw an exception should mean that we should return
true. So we end up with:

setPropertyMethodBool.invoke(o, params);
return true;

-Tim

On Wed, Oct 5, 2011 at 11:44 AM,  wrote:

> Author: kkolinko
> Date: Wed Oct  5 15:44:58 2011
> New Revision: 1179274
>
> URL: http://svn.apache.org/viewvc?rev=1179274&view=rev
> Log:
> Resolve a warning about unboxing operation. Perform unboxing explicitly.
>
> Modified:
>tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java
>
> Modified: tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java?rev=1179274&r1=1179273&r2=1179274&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/IntrospectionUtils.java Wed
> Oct  5 15:44:58 2011
> @@ -359,7 +359,8 @@ public final class IntrospectionUtils {
> params[1] = value;
> if (setPropertyMethodBool != null) {
> try {
> -return (Boolean) setPropertyMethodBool.invoke(o,
> params);
> +return ((Boolean) setPropertyMethodBool.invoke(o,
> +params)).booleanValue();
> }catch (IllegalArgumentException biae) {
> //the boolean method had the wrong
> //parameter types. lets try the other
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: svn commit: r1177245 - /tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java

[Tim Funk]

Wouldn't converting the whole method to use StringBuilder be more efficient
- as compared instantiating a StringWriter AND PrintWriter? We could
probably guess a good default size too of size()*40 which would assume most
headers are less than 40 chars (which is typically true except for
user-agent and cookie)

But as the previous commit noted .. its a debug method so it may not really
matter.

-Tim

On Thu, Sep 29, 2011 at 5:52 AM,  wrote:

> Author: kkolinko
> Date: Thu Sep 29 09:52:56 2011
> New Revision: 1177245
>
> URL: http://svn.apache.org/viewvc?rev=1177245&view=rev
> Log:
> A bit more memory-efficient code.
>
> Modified:
>tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java
>
> Modified: tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java?rev=1177245&r1=1177244&r2=1177245&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java
> (original)
> +++ tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java Thu Sep
> 29 09:52:56 2011
> @@ -145,7 +145,9 @@ public class MimeHeaders {
> String n = e.nextElement();
> Enumeration ev = values(n);
> while (ev.hasMoreElements()) {
> -pw.println(n + " = " + ev.nextElement());
> +pw.print(n);
> +pw.print(" = ");
> +pw.println(ev.nextElement());
> }
> }
> return sw.toString();
>
>
>

Re: svn commit: r1163643 - /tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java

[Tim Funk]

/me confused - should this be removed from trunk instead of tc7.0.x?

-Tim

On Wed, Aug 31, 2011 at 10:31 AM,  wrote:

> Author: markt
> Date: Wed Aug 31 14:31:13 2011
> New Revision: 1163643
>
> URL: http://svn.apache.org/viewvc?rev=1163643&view=rev
> Log:
> As per the comment, remove the deprecated code
>
> Modified:
>tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
>
> Modified:
> tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
> URL:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java?rev=1163643&r1=1163642&r2=1163643&view=diff
>
> ==
> --- tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
> (original)
> +++ tomcat/tc7.0.x/trunk/java/org/apache/jasper/JspCompilationContext.java
> Wed Aug 31 14:31:13 2011
> @@ -385,49 +385,6 @@ public class JspCompilationContext {
> return jspUri;
> }
>
> -/**
> - * @deprecated Will be removed in Tomcat 8.0.x. Use
> - * {@link #getLastModified(String)} instead.
> - */
> -@Deprecated
> -public long getJspLastModified() {
>
>

Re: [VOTE] Grant Olivier Lamy commit karma to the Tomcat repo (for the Maven plugin)

[Tim Funk]

+1

On Thu, Aug 25, 2011 at 10:44 AM, Mark Thomas  wrote:

> Subject says it all.
>
> Here is my +1 to start this off.
>
>

Re: svn commit: r1156530 - in /tomcat/trunk/java/org/apache/catalina/connector: LocalStrings.properties Response.java

[Tim Funk]

It may be overkill ... but should "absolute" be XML escaped?

-Tim


On Thu, Aug 11, 2011 at 4:13 AM,  wrote:

> Modified: tomcat/trunk/java/org/apache/catalina/connector/Response.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Response.java?rev=1156530&r1=1156529&r2=1156530&view=diff
>
> ==
> +PrintWriter writer = getWriter();
> +writer.print(
> +sm.getString("coyoteResponse.sendRedirect.note",
> absolute));
> +flushBuffer();
> } catch (IllegalArgumentException e) {
> setStatus(SC_NOT_FOUND);
> }
>
>

Re: Servlet 3.1, Tomcat 8 etc.

[Tim Funk]

+1 To getting newer ideas in faster.

I guess the question to ponder is what are the future changes pending for 7?
What are the changes for the servlet spec?

I have a feeling that the servlet spec changes are more of a playground for
ideas which would bring about lots of change and potential reversions. With
that in mind - it seems like it belongs in the sandbox. But sandbox might
imply a private playground or its a ghetto (american slang) area of the
repository that only the brave should wander into. So to test servlet spec
changes, would it be better to create a branch called servlet3.1 so if new
ideas come into trunk - they might not conflict for servlet 3.1 concepts?
Then once servlet 3.1 goes into public review (or some similar status) -
then the changes get merged back into trunk and tomcat7 gets its own branch?

-Tim

On Tue, Jul 26, 2011 at 1:30 PM, Mark Thomas  wrote:

> The Servlet EG is starting to discuss changes to the Servlet API for
> 3.1. It would be useful if the option existed to implement some of these
> changes in Tomcat trunk. The benefits of this are:
> - we can see how feasible the API changes are to implement
> - users can try out the new APIs (assuming we do a Tomcat 8 alpha release)
>
> Therefore, after the next Tomcat 7 release, I would like to do the
> following:
> - Copy tomcat/trunk to tomcat/tc7.0.x/trunk
> - Start making Servlet API changes to tomcat/trunk
>
> Assuming that there are no objections to that plan, that leads to a
> couple of other questions.
>
> 1. Should tomcat/tc7.0.x/trunk be RTC or CTR?
>
> 2. With tomcat/trunk becoming the basis for Tomcat 8, I would like to
> see earlier and more frequent alpha/beta releases than we had for Tomcat
> 7. That would increase the effective number of versions we are
> supporting. With that in mind, should we announce end of support for
> 5.5.x with the last release expected in ~12 months time?
>
>

Re: svn commit: r1140204 - /tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java

[Tim Funk]

The javadocs say it can be an "expensive" operation. But considering the
alternatives [and this is only done once],  this seems to be reasonable.
What could be worrisome is the JDK does allow for more charsets to be added
at run-time. In which case - a user could be out of luck.

If we were scared of performance at startup .. we could always have a
System.properties of comma separated entries as the source of charset names
instead of worrying about Charset.availableCharsets(). In which case
"iso8859-1,utf-8" might be enough for some users.

-Tim


On Mon, Jun 27, 2011 at 11:49 AM, Konstantin Kolinko  wrote:

> 2011/6/27  :
> > Author: markt
> > Date: Mon Jun 27 15:19:22 2011
> > New Revision: 1140204
> >
> > URL: http://svn.apache.org/viewvc?rev=1140204&view=rev
> > Log:
> > Need to include aliases in charset cache
> >
> > Modified:
> >tomcat/trunk/java/org/apache/tomcat/util/buf/B2CConverter.java
> >
> I was wondering how slow is Charset.availableCharsets().
> In my test it is about 100ms.  Nothing to worry about.
>
>

Re: svn commit: r1136231 - in /tomcat/trunk: java/org/apache/catalina/ssi/ExpressionParseTree.java webapps/docs/changelog.xml

[Tim Funk]

**
What happens if PatternSyntaxException is thrown? (bad regex is passed in)
While it is a RuntimeException - i'd assume you'd want to log.warn(with the
regex) and return -1;


-Tim

On 6/15/2011 6:44 PM, ma...@apache.org wrote:

Modified: tomcat/trunk/java/org/apache/catalina/ssi/ExpressionParseTree.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ssi/ExpressionParseTree.java?rev=1136231&r1=1136230&r2=1136231&view=diff
==
@@ -350,6 +351,21 @@ public class ExpressionParseTree {
 protected int compareBranches() {
 String val1 = ((StringNode)left).getValue();
 String val2 = ((StringNode)right).getValue();
+
+int val2Len = val2.length();
+if (val2Len > 1 && val2.charAt(0) == '/' &&
+val2.charAt(val2Len - 1) == '/') {
+// Treat as a regular expression
+String expr = val2.substring(1, val2Len - 1);
+Pattern pattern = Pattern.compile(expr);
+// Regular expressions will only ever be used with EqualNode
+// so return zero for equal and non-zero for not equal
+if (pattern.matcher(val1).find()) {
+return 0;
+} else {
+return -1;
+}
+}

Re: svn commit: r1132487 - in /tomcat/trunk: java/org/apache/coyote/http11/AbstractHttp11Processor.java webapps/docs/changelog.xml

[Tim Funk]

Ascii.parseInt can throw a NumberFormatException which should probably be
caught and a 400 returned.

-Tim

On Sun, Jun 5, 2011 at 4:26 PM,  wrote:

> Author: markt
> Date: Sun Jun  5 20:26:37 2011
> New Revision: 1132487
>
> URL: http://svn.apache.org/viewvc?rev=1132487&view=rev
> Log:
> Parse port as base10, not hex
>
> Modified:
>tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
>tomcat/trunk/webapps/docs/changelog.xml
>
> Modified:
> tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java?rev=1132487&r1=1132486&r2=1132487&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> (original)
> +++ tomcat/trunk/java/org/apache/coyote/http11/AbstractHttp11Processor.java
> Sun Jun  5 20:26:37 2011
> @@ -39,7 +39,6 @@ import org.apache.juli.logging.Log;
>  import org.apache.tomcat.util.ExceptionUtils;
>  import org.apache.tomcat.util.buf.Ascii;
>  import org.apache.tomcat.util.buf.ByteChunk;
> -import org.apache.tomcat.util.buf.HexUtils;
>  import org.apache.tomcat.util.buf.MessageBytes;
>  import org.apache.tomcat.util.http.FastHttpDateFormat;
>  import org.apache.tomcat.util.http.MimeHeaders;
> @@ -993,26 +992,9 @@ public abstract class AbstractHttp11Proc
> }
> request.serverName().setChars(hostNameC, 0, valueL);
> } else {
> -
> request.serverName().setChars(hostNameC, 0, colonPos);
> -
> -int port = 0;
> -int mult = 1;
> -for (int i = valueL - 1; i > colonPos; i--) {
> -int charValue = HexUtils.getDec(valueB[i + valueS]);
> -if (charValue == -1) {
> -// Invalid character
> -error = true;
> -// 400 - Bad request
> -response.setStatus(400);
> -adapter.log(request, response, 0);
> -break;
> -}
> -port = port + (charValue * mult);
> -mult = 10 * mult;
> -}
> -request.setServerPort(port);
> -
> +request.setServerPort(Ascii.parseInt(
> +valueB, valueS + colonPos + 1, valueL - colonPos -
> 1));
> }
>
> }
>
>

Re: svn commit: r1131263 - in /tomcat/trunk: java/org/apache/catalina/session/JDBCStore.java java/org/apache/catalina/session/LocalStrings.properties webapps/docs/changelog.xml webapps/docs/config/man

[Tim Funk]

If NamingExceptionOccurs - should this instead rethrow a SqlException
instead of letting the logic keep going? Otherwise wouldn't a SqlException
be thrown later in the method?

-Tim

On Fri, Jun 3, 2011 at 6:13 PM,  wrote:

> Author: markt
> Date: Fri Jun  3 22:13:09 2011
> New Revision: 1131263
>
> URL: http://svn.apache.org/viewvc?rev=1131263&view=rev
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51264
> Allow the JDBC persistent session store to use a JNDI datasource to define
> the database in which sessions are persisted.
> Patch provided by Felix Schumacher.
>
> Modified:
>tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java
>tomcat/trunk/java/org/apache/catalina/session/LocalStrings.properties
>tomcat/trunk/webapps/docs/changelog.xml
>tomcat/trunk/webapps/docs/config/manager.xml
>
> Modified: tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java?rev=1131263&r1=1131262&r2=1131263&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java (original)
> +++ tomcat/trunk/java/org/apache/catalina/session/JDBCStore.java Fri Jun  3
> 22:13:09 2011
> @@ -866,6 +902,24 @@ public class JDBCStore extends StoreBase
> if (dbConnection != null)
> return (dbConnection);
>
> +if (dataSourceName != null && dataSource == null) {
> +Context initCtx;
> +try {
> +initCtx = new InitialContext();
> +Context envCtx = (Context)
> initCtx.lookup("java:comp/env");
> +this.dataSource = (DataSource)
> envCtx.lookup(this.dataSourceName);
> +} catch (NamingException e) {
> +manager.getContainer().getLogger().error(
> +sm.getString(getStoreName() + ".wrongDataSource",
> +this.dataSourceName), e);
> +   }
> +}
> +
> +if (dataSource != null) {
> +dbConnection = dataSource.getConnection();
> +return dbConnection;
> +}
> +
>

Re: Outdated Servlet 3.0 Javadocs available on tomcat.apache.org

[Tim Funk]

Doh - Older specs had the javadocs. I never scrolled to the end to notice it
missing from the current spec.

-Tim

On Wed, Jun 1, 2011 at 11:29 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Tim,
>
> On 6/1/2011 8:35 AM, Tim Funk wrote:
> > Is the PDF of the spec which is downloadable up to date with respect to
> > comments?
>
> The version of the PDF I'm looking at (3.0 Final, 1434610 bytes, dated
> 10 December 2009) does not include the javadoc at all... it does include
> some documentation of certain methods... I have only done a casual
> reading at this point.
>

Re: Outdated Servlet 3.0 Javadocs available on tomcat.apache.org

[Tim Funk]

Is the PDF of the spec which is downloadable up to date with respect to
comments? I don't think the pdf version of the spec is CDDL ... but it may
have other conditions on it. If the PDF version of the spec is up to date,
someone might be able to copy from the PDF and paste into the javadocs and
add the correct formatting.

-Tim

On Wed, Jun 1, 2011 at 4:57 AM, Mark Thomas  wrote:

>
> Those comments are part of CDDL licensed source code. My reading of
> http://www.apache.org/legal/resolved.html#category-b is that we can't
> copy the comments directly into our source code.
>
>

Re: Fixing bug 33453

[Tim Funk]

 How about calling it getDependantsMap() instead of getDependants() ?

Then catch the NoSuchMethodException (I in the case where the compiled jsp
doesn't have getDependants() and that would force a recompile (and then the
new version would be OK)

-Tim

On 5/20/2011 12:31 PM, Mark Thomas wrote:

All,

I've been looking at [1]. Ignoring the flames, there do appear to be
several use cases where the current time-stamp checks are insufficient
(although there are simple work-arounds). I have a patch [2] but I don't
particularly like the fact that it breaks binary compatibility with JSPs
compiled with an earlier version. My instinct is that this is bad. What
does everyone else think?

I do have an idea for addressing this:
- Leave JspSourceDependent as is in 7.0.14 but deprecate it
- Add a new JspSourceDependent2 interface (better names welcome)
- Compilation always uses JspSourceDependent2
- Isoutdated checked for JspSourceDependent as well as
JspSourceDependent2 and any classes implementing JspSourceDependent are
treated as outdated.

Thoughts?

Mark

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=33453
[2] https://issues.apache.org/bugzilla/attachment.cgi?id=27040&action=diff

Re: [PROPOSAL] Move to svnpubsub for /dist/tomcat

[Tim Funk]

+1

On Wed, May 18, 2011 at 9:38 AM, Mark Thomas  wrote:

>
> We have the option to move to svnpubsub for managing our releases.
> Rather than copying artefacts to people.a.o and then waiting for rsync
> (every around 2 hours) we would commit the artefacts to svn and a commit
> hook would update the /dist/tomcat area on the www servers immediately.
>
> If folks would like to go this route, I am happy to do the work on our
> end to migrate /dist/tomcat to svnpubsub.
>
>

Re: BIO performance issues

[Tim Funk]

Solution B and disabling keepalive when a threshold is reached looks to be
the way to go. If people have issue with that, that's why the other
connectors exist.

-Tim


On Tue, May 3, 2011 at 4:02 PM, Mark Thomas  wrote:


>
> Solution B
> --
> Return to the Tomcat 6 implementation where maxConnections == maxThreads.
>
> Additional clean-up
> ---
> maxConnections is unnecessary in APR since pollerSize performs the same
> function.
>
> Summary
> ---
> The proposed changes are:
> a) restore disabling keep-alive when threads used >= 75% of maxThreads
> b) remove maxConnections and associated code from the APR connector
> c) remove the configuration options for maxConnections from the BIO
> connector
> d) use maxThreads instead of maxConnections for the BIO connector
> e) update the docs
>
>
>

Re: svn commit: r1087128 - in /tomcat/trunk: java/org/apache/catalina/util/SessionIdGenerator.java webapps/docs/changelog.xml

[Tim Funk]

Would it be more "efficient" to do this instead?

-/** Node identifier when in a cluster. Defaults to the empty string. */
-private String jvmRoute = "";
+/** Node identifier when in a cluster.  */
+private String jvmRoute = null;
...
 public void setJvmRoute(String jvmRoute) {
if (jvmRoute!=null&&jvmRoute.length()==0) {
jvmRoute=null;
}
 this.jvmRoute = jvmRoute;
 }


-Tim

On 3/30/2011 7:09 PM, ma...@apache.org wrote:

Author: markt
Date: Wed Mar 30 23:09:10 2011
New Revision: 1087128

URL: http://svn.apache.org/viewvc?rev=1087128&view=rev
Log:
Don't append the jvmRoute to a session ID if the jvmRoute is a zero length 
string.

Modified:
 tomcat/trunk/java/org/apache/catalina/util/SessionIdGenerator.java
 tomcat/trunk/webapps/docs/changelog.xml

Modified: tomcat/trunk/java/org/apache/catalina/util/SessionIdGenerator.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/util/SessionIdGenerator.java?rev=1087128&r1=1087127&r2=1087128&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/util/SessionIdGenerator.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/util/SessionIdGenerator.java Wed Mar 
30 23:09:10 2011
@@ -168,7 +168,7 @@ public class SessionIdGenerator {
  }
  }

-if (jvmRoute != null) {
+if (jvmRoute != null&&  jvmRoute.length()>  0) {
  buffer.append('.').append(jvmRoute);
  }


Modified: tomcat/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1087128&r1=1087127&r2=1087128&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Mar 30 23:09:10 2011
@@ -128,6 +128,10 @@
  name ending in.jar  to be treated as an expanded JAR file
  by the default JarScanner. Based on patch by Rodion Zhitomirsky. 
(markt)

+
+Don't append the jvmRoute to a session ID if the jvmRoute is a 
zero
+length string. (markt)
+
  





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Reaching ulimit values for open files can generate huge log files

[Tim Funk]

Sorry - I meant to say - since the existing setSocketOptions() is in the 
try/catch block as accept(). Is it possible for a network client to send 
an ip packet to cause a failure and throw a SocketException while 
internally tomcat is setting each of the socket options? So the net 
effect is - the errorDelay value is set causing which makes endPoint 
fall asleep. Which could be a client induced DOS attack.


So in the context above: user/client is someone on the network end, not 
the admin of the box. If the admin puts a config option in which causes 
setSocketOptions() to fail ... that is their problem.


-Tim


On 2/23/2011 5:48 AM, Mark Thomas wrote:

On 21/02/2011 17:33, Tim Funk wrote:

Do you want to limit the try/catch scope to just
serverSocketFactory.acceptSocket since setSocketOptions() can also throw
IOException?


A couple of people have mentioned this and while the current code would
be OK with a broader try/catch I like the idea of a limited try/catch
since that makes it obvious what the code is doing.


Is there a case where a client can induce an exception while
setSocketOptions() is processing?


I don't think so but let's not give them the opportunity.

In terms of making this configurable, I'm minded not to initially. We
can always add configuration options if users request them later.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Reaching ulimit values for open files can generate huge log files

[Tim Funk]

Do you want to limit the try/catch scope to just 
serverSocketFactory.acceptSocket since setSocketOptions() can also throw 
IOException?


Is there a case where a client can induce an exception while 
setSocketOptions() is processing?



-Tim

On 2/21/2011 10:21 AM, Mark Thomas wrote:

The ASF Sonar installation managed to generate 46GB of identical log
messages [1] today in the 8 hours it took to notice it was down.

While better monitoring would/should have identified the problem sooner,
it does demonstrate a problem with the acceptor threads in all three
endpoints. If there is a system-level issue that causes the accept()
call to always fail (such as hitting the ulimit) then the endpoint
essentially enters a loop where it logs an error message for every
iteration of the loop. This will result in many log messages per second.

I'd like to do something about this. I was thinking of something along
the lines of the following for each endpoint.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1060627 - in /tomcat/trunk/webapps: docs/changelog.xml host-manager/META-INF/context.xml manager/META-INF/context.xml

[Tim Funk]

My bad - I meant +1 to having it for real.


-Tim

On 1/19/2011 1:48 PM, Mark Thomas wrote:

On 19/01/2011 01:18, Tim Funk wrote:

+1 - It might be nice to match 127.0.0.[0-9]{1,3} so it is more virtual
machine friendly for those who map localhost to an alternate loopback
address.


+1 to having it as a comment, or +1 to removing the comment and having
it there for real?

Either way I'll update the regex (I'll also see what the IPv6 equivalent is)

Mark



-Tim

On 1/18/2011 7:04 PM, Mark Thomas wrote:

On 19/01/2011 00:00, ma...@apache.org wrote:

Author: markt
Date: Wed Jan 19 00:00:59 2011
New Revision: 1060627

URL: http://svn.apache.org/viewvc?rev=1060627&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=22278
Add a commented out RemoteAddrValve that limits access to the Manager
and Host Manager applications to localhost.
Based on a patch by Yann Cébron.


I thought about extending this and enabling the Valve by default along
with adding additional information to the 403 error page.

Whilst I like to from a security point of view, I do wonder how much
stuff it would break for users and how much traffic it would generate on
the users list.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1060627 - in /tomcat/trunk/webapps: docs/changelog.xml host-manager/META-INF/context.xml manager/META-INF/context.xml

[Tim Funk]

+1 - It might be nice to match 127.0.0.[0-9]{1,3} so it is more virtual 
machine friendly for those who map localhost to an alternate loopback 
address.


-Tim

On 1/18/2011 7:04 PM, Mark Thomas wrote:

On 19/01/2011 00:00, ma...@apache.org wrote:

Author: markt
Date: Wed Jan 19 00:00:59 2011
New Revision: 1060627

URL: http://svn.apache.org/viewvc?rev=1060627&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=22278
Add a commented out RemoteAddrValve that limits access to the Manager and Host 
Manager applications to localhost.
Based on a patch by Yann Cébron.


I thought about extending this and enabling the Valve by default along
with adding additional information to the 403 error page.

Whilst I like to from a security point of view, I do wonder how much
stuff it would break for users and how much traffic it would generate on
the users list.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat 7.0.x. still CTR?

[Tim Funk]

My preference is to remain CTR on the idea the anything of significance 
be proposed so there would be consensus to push it into 7.0 or branch to 7.X


-Tim


On 1/18/2011 1:41 PM, Christopher Schultz wrote:

All,

Since Tomcat 7.0.x went stable, does that change the commit policy, or
are we still doing commit-them-review?


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1058102 - in /tomcat/trunk: java/org/apache/jasper/compiler/Generator.java java/org/apache/jasper/compiler/JspUtil.java webapps/docs/changelog.xml

[Tim Funk]

Interesting. Nice nugget to know.

-Tim

On 1/12/2011 10:09 AM, Mark Thomas wrote:

On 12/01/2011 15:08, Tim Funk wrote:

JspFactory is in package javax.servlet.jsp which is one of the packages
that has  * import. If a user tried to create a class called JspFactory
and tried to import it - he'd get a compile error on his import statement.


There would be no exception. Explicit import takes precedence over * import.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1058102 - in /tomcat/trunk: java/org/apache/jasper/compiler/Generator.java java/org/apache/jasper/compiler/JspUtil.java webapps/docs/changelog.xml

[Tim Funk]

JspFactory is in package javax.servlet.jsp which is one of the packages 
that has  * import. If a user tried to create a class called JspFactory 
and tried to import it - he'd get a compile error on his import statement.



-Tim

On 1/12/2011 10:04 AM, Mark Thomas wrote:

On 12/01/2011 14:51, Tim Funk wrote:

I don't understand what this change other than provide noise. It doesn't
fix anything.


It protects against a user importing org.foo.JspFactory in their JSP
and breaking JSP compilation.

Granted it is unlikely, but the JSP spec doesn't prevent a user from
doing that (however stupid you or I may think such a class name is).

Mark




-Tim

On 1/12/2011 7:08 AM, ma...@apache.org wrote:

Author: markt
Date: Wed Jan 12 12:08:16 2011
New Revision: 1058102

URL: http://svn.apache.org/viewvc?rev=1058102&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=15688
Use fully qualified class names to avoid possible naming conflicts
JSP 2.2 TCK passes with these changes

Modified:
  tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
  tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java
  tomcat/trunk/webapps/docs/changelog.xml



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1058102 - in /tomcat/trunk: java/org/apache/jasper/compiler/Generator.java java/org/apache/jasper/compiler/JspUtil.java webapps/docs/changelog.xml

[Tim Funk]

I don't understand what this change other than provide noise. It doesn't 
fix anything.



-Tim

On 1/12/2011 7:08 AM, ma...@apache.org wrote:

Author: markt
Date: Wed Jan 12 12:08:16 2011
New Revision: 1058102

URL: http://svn.apache.org/viewvc?rev=1058102&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=15688
Use fully qualified class names to avoid possible naming conflicts
JSP 2.2 TCK passes with these changes

Modified:
 tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
 tomcat/trunk/java/org/apache/jasper/compiler/JspUtil.java
 tomcat/trunk/webapps/docs/changelog.xml



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.30

[Tim Funk]

> [X] Stable

-Tim

On 1/10/2011 12:18 PM, jean-frederic clere wrote:

The candidates binaries are available here:
http://people.apache.org/~jfclere/tomcat-6/v6.0.30/

According to the release process, the 6.0.30 build corresponding to the
tag TOMCAT_6_0_30 is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.6

[Tim Funk]

> [X] Stable - go ahead and release as 7.0.6 Stable

-Tim

On 1/10/2011 1:54 PM, Mark Thomas wrote:

The proposed Apache Tomcat 7.0.6 release is now available for voting.

It can be obtained from:
http://people.apache.org/~markt/dev/tomcat-7/v7.0.6/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_6/

The proposed 7.0.6 release is:

[ ] Broken - do not release
[ ] Alpha  - go ahead and release as 7.0.6 Alpha
[ ] Beta   - go ahead and release as 7.0.6 Beta
[ ] Stable - go ahead and release as 7.0.6 Stable



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat 7 & regex

[Tim Funk]

I am thinking from an admin point of view. While you can combine OR 
conditionals in regex's - when you get something more complicated - you 
may encounter a nasty nesting of () to get all the nested OR's correct. 
So while one COULD to it in a single regex - most mere mortals might not 
be able to comprehend that regex. This is where combining different 
regexes by a user defined split may come in handy.


But in reality ... the general case a user is doing is probably a 
singular regex. So since the capability exists for more exotic matches, 
it may be easier to simplify the code per your (mark's) suggestion and 
then provide enough coaching to demonstrate how more advanced regexes 
can be applied.


(So I am cool with it. Time permitting - I'll try to provide an example 
or 2 for odd regexes - like RFC1918 matching for the RemoteAddrressFilter)


-Tim

On 12/25/2010 2:53 PM, Mark Thomas wrote:

On 25/12/2010 01:49, Tim Funk wrote:

+0.5 - I wonder if in some cases - it may be preferable to use a
property called split which lets the user define the separator which we
can pass to String.split(). [Which OTOH may be more confusing (yet
powerful) since the user is using a regex to split get a list of regex]


I think that just makes it more complicated. There is no need to split
anything up since the regex can just use |. Rather than mix regex plus
our own proprietary splitting mechanism, I think we should just use the
support already provided by regex to do the same thing.

Mark



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Tomcat 7 & regex

[Tim Funk]

+0.5 - I wonder if in some cases - it may be preferable to use a 
property called split which lets the user define the separator which we 
can pass to String.split(). [Which OTOH may be more confusing (yet 
powerful) since the user is using a regex to split get a list of regex]


-Tim

On 12/24/2010 1:34 PM, Mark Thomas wrote:

There are a number of configuration properties defined as "comma
separated regular expressions". As someone pointed out at at ApacheCon
that is a little odd. It stops "," being used in an expression and is
inefficient.

Having just been bitten by this while setting up the new Jira instance,
I intend change all properties that take regex in Tomcat 7 to use a
single regex. This will simplify the code, simplify configuration and
make the regex processing faster.

I probably won't get around to actually doing this until the new year.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/

[Tim Funk]

Sorry for the additional noise ... my svn emails are in a different 
folder from dev emails. I just noticed ...


svn commit: r1039882 - 
/tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java


-Tim

On 11/29/2010 7:40 AM, Tim Funk wrote:

I checked the svn history of why MD5 (hashing was used) and the picture
is incomplete. (unless someone asks craig since I think he was the author)

But it appears like this ...
Tomcat 3.X use Math.random() and some misc crap to generate its session
id. It had a comment (paraphrased), "not secure for banking/military use
for creating session ID. "

Then in tomcat 4.0 - we see the code as it is now. It has always tried
to use SecureRandom. What is interesting is SecureRandom's javadocs in
1.2 (JDK) are different than 1.4. (And maybe 1.3) By the time we get to
Java 1.4 - SecureRandom is advertised as cryptographically strong. So
back in the day of 1.2 - there was no guarantee there. Or maybe is
wasn't cross platform guaranteed.

So back in the day ... you might be able to get a stream of session ids
... and then determine where you are in the sequence of random number
generation. (Recall that randoms aren't really random, its just an
algorithm on a seed) An "easy" way to thwart this attack - is to hash
the numbers. Making it orders of magnitude harder determine what the
numbers generated the session ID. (For this type of deception, any
hashing function is still OK even with the collision issues)

So that leaves us to where we are now. Interestingly enough ... RFC1750
(as listed in the SecureRandom javadoc) discourages the use of current
time as a seed because the window to guess the seed is now orders of
magnitude smaller.

Since all instances of Random are self seeding, it may be best (ask you
local JVM expert for opinion) to allow the JVM to decide the seed. In
which case - it may go to the hardware, use /dev/urandom, etc. Which
would be much better than anything we can do.

As for hash or not to hash. I am unsure. If the seed IS quality, and the
random algorithm is quality - then there is no need to hash. But if we
allow reality to intervene - then we might accept that some platforms
might not have a quality seed, or one of the algorithms might come under
attack and no longer be good. In which case - hashing becomes a good
defense.


So to collect all the thoughts above ... it might be nice to do the
following
- Force use of SecureRandom (and still allow it to be extended)
- Turn hashing off (but leave it as an option)
- When initializing SecureRandom - do nothing. Let the JVM take care of it.
- Allow /dev/urandom to override the previous statement.

Then if any of the above is unacceptable ... the user can just provide
their own extended version of SecureRandom.


-Tim

On 11/26/2010 1:46 PM, Remy Maucherat wrote:

On Thu, 2010-11-25 at 16:33 +, Mark Thomas wrote:

I wouldn't call it bad. It doesn't do any harm (apart from adding a very
small amount of overhead), and it would help if the random source
selected ended up not being that random.

I thought the trade-off of protection against bad choices of random
sources was worth the minimal overhead added. I'm not against removing
it entirely, if there is consensus to do so.


MD5 is now known as a bad hash (it was fine at the time the code was
written), so does it actually improve anything ?

Also, isn't SecureRandom always available now ? This is 10+ years old
code, probably.


For SecureRandom, yes. I did test this locally and it achieves
thread-safety by using an internal sync and it did create a significant
bottleneck. That is why I went the parallel route. Reading from a stream
has a similar sync so again that is why I went the parallel route.


Ok. The internal lock is a much smaller sync than the old sync block, so
it would be a bit better. It is possible it is noticeable, though. The
question is if this yields a good enough session creation rate.


How about this as an approach to reduce the complexity:
1. Remove the MD5 code (optional)
2. Default to /dev/urandom then SecureRandom. Don't fall back to Random.
3. Provide a class that implements Random that reads data from a file
4. If randomFile is specified, use the the class from 3 as the Random
source

That should reduce the current 3 Queues to one. I doubt it will improve
performance much but it should make the code clearer.

Thoughts?


I don't know what the best solution is. /dev/urandom could also only be
used as seed only to a SecureRandom, this is more Javaish.
So about the MD5, I don't think it is useful anymore.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1036595 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ test/org/apache/catalina/session/

[Tim Funk]

I checked the svn history of why MD5 (hashing was used) and the picture 
is incomplete. (unless someone asks craig since I think he was the author)


But it appears like this ...
Tomcat 3.X use Math.random() and some misc crap to generate its session 
id. It had a comment (paraphrased), "not secure for banking/military use 
for creating session ID. "


Then in tomcat 4.0 - we see the code as it is now. It has always tried 
to use SecureRandom. What is interesting is SecureRandom's javadocs in 
1.2 (JDK) are different than 1.4. (And maybe 1.3) By the time we get to 
Java 1.4 - SecureRandom is advertised as cryptographically strong. So 
back in the day of 1.2 - there was no guarantee there. Or maybe is 
wasn't cross platform guaranteed.


So back in the day ... you might be able to get a stream of session ids 
... and then determine where you are in the sequence of random number 
generation. (Recall that randoms aren't really random, its just an 
algorithm on a seed) An "easy" way to thwart this attack - is to hash 
the numbers. Making it orders of magnitude harder determine what the 
numbers generated the session ID. (For this type of deception, any 
hashing function is still OK even with the collision issues)


So that leaves us to where we are now. Interestingly enough ... RFC1750 
(as listed in the SecureRandom javadoc) discourages the use of current 
time as a seed because the window to guess the seed is now orders of 
magnitude smaller.


Since all instances of Random are self seeding, it may be best (ask you 
local JVM expert for opinion) to allow the JVM to decide the seed. In 
which case - it may go to the hardware, use /dev/urandom, etc. Which 
would be much better than anything we can do.


As for hash or not to hash. I am unsure. If the seed IS quality, and the 
random algorithm is quality - then there is no need to hash. But if we 
allow reality to intervene - then we might accept that some platforms 
might not have a quality seed, or one of the algorithms might come under 
attack and no longer be good. In which case - hashing becomes a good 
defense.



So to collect all the thoughts above ... it might be nice to do the 
following

- Force use of SecureRandom (and still allow it to be extended)
- Turn hashing off (but leave it as an option)
- When initializing SecureRandom - do nothing. Let the JVM take care of it.
- Allow /dev/urandom to override the previous statement.

Then if any of the above is unacceptable ... the user can just provide 
their own extended version of SecureRandom.



-Tim

On 11/26/2010 1:46 PM, Remy Maucherat wrote:

On Thu, 2010-11-25 at 16:33 +, Mark Thomas wrote:

I wouldn't call it bad. It doesn't do any harm (apart from adding a very
small amount of overhead), and it would help if the random source
selected ended up not being that random.

I thought the trade-off of protection against bad choices of random
sources was worth the minimal overhead added. I'm not against removing
it entirely, if there is consensus to do so.


MD5 is now known as a bad hash (it was fine at the time the code was
written), so does it actually improve anything ?

Also, isn't SecureRandom always available now ? This is 10+ years old
code, probably.


For SecureRandom, yes. I did test this locally and it achieves
thread-safety by using an internal sync and it did create a significant
bottleneck. That is why I went the parallel route. Reading from a stream
has a similar sync so again that is why I went the parallel route.


Ok. The internal lock is a much smaller sync than the old sync block, so
it would be a bit better. It is possible it is noticeable, though. The
question is if this yields a good enough session creation rate.


How about this as an approach to reduce the complexity:
1. Remove the MD5 code (optional)
2. Default to /dev/urandom then SecureRandom. Don't fall back to Random.
3. Provide a class that implements Random that reads data from a file
4. If randomFile is specified, use the the class from 3 as the Random source

That should reduce the current 3 Queues to one. I doubt it will improve
performance much but it should make the code clearer.

Thoughts?


I don't know what the best solution is. /dev/urandom could also only be
used as seed only to a SecureRandom, this is more Javaish.
So about the MD5, I don't think it is useful anymore.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1036150 - /tomcat/trunk/webapps/docs/changelog.xml

[Tim Funk]

If the Random number generator is "sufficiently random" could we avoid 
the digesting? Or should it be an option?


Since java1.6 has SecureRandom - is its current implementation good 
enough to avoid all the extra tricks currently being done and we can 
just use that as a default? [Or maybe - we should extend Random and use 
that as the default Random instance and move all the initialization 
seed/entropy/etc into that class.]


The decision to hash was one made a long time ago (before my time) and 
probably was done with respect to not having SecureRandom and other 
oddities surrounding the problem of seeding. Do those problems still 
exist - or do they exist on some platforms.


-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PATCH] Parallel deployment

[Tim Funk]

This might cause a problem of using == instead of equals() for strcmp

if (version == (request.getContext().getWebappVersion())) {
mapRequired = false;
}


When running mod_jk with sticky session, but not using tomcat clustering 
... Will adding a new version append the version number to the end of 
the session cookie AFTER the engineId (used by mod_jk for determining 
where to route the request)


Since the session id tomcat generates is always all uppercase. Should 
the 'V' for the append be a lower case v? Even though session id 
collision is *rare*, but using a char that isn't in the session id name 
space would eliminate that problem.


Otherwise +1. For those who are uninterested in the feature, it appears 
the extra overhead is minimal. (Some micro benchmarks would be nice for 
any skeptics ... or those just curious :) )


-Tim


On 11/5/2010 9:08 PM, Mark Thomas wrote:

All,

The clean-up is in place and I have a patch [1] that adds support for
parallel deployment. There is still some work to do before the feature
can be used (Manager app needs to be made version aware when listing
apps, need to test with clustering, need to write some docs) but I'd
like to apply this patch sooner rather than later so the code is in
place for the next release.

Behaviour should remain unchanged unless someone deploys an app with the
version marker (##) at the end of the WAR / dir / context.xml
name so even if the todo list above isn't complete it shouldn't get in
the way of the next release.

Before I apply the patch I wanted to give folks an opportunity to review
and comment on whether or not it was too big a change for the 7.0.x
branch at this stage. My own view is that it is not.

Cheers,

Mark


[1]
http://people.apache.org/~markt/patches/2010-11-05-parallel-deployment.patch



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: configtest

[Tim Funk]

"svn diff -x -w" version uploaded. I always wondered how to ignore 
whitespace in svn ignore. (It bugged me, but never enough to rtfm) 
Thanks for the tip!



-Tim


On 11/3/2010 6:46 PM, Konstantin Kolinko wrote:


Too many unneeded whitespace changes. It is hard to read. Try
svn diff -x -w


In essence, it is
+} else if (command.equals("configtest")) {
+daemon.load(args);
+if (null==daemon.getServer()) {
+System.exit(1);
+}
+System.exit(0);

where load(args) processes command line arguments, parses server.xml
and also calls  getServer().init();



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

configtest

[Tim Funk]

A possible nice to have is trying to "test" whether a new config will be 
OK or not.I have a patch which will allow a new arg for catalina.sh 
called "configtest".


It will try to load the catalina config but log everything to standard 
output. It will try to exit with a non zero status code if "bad things 
happen". But it is not full proof, I have very quickly found ways to put 
in bad values that allows tomcat to start but I'd probably prefer it die 
instead.


Anyway .. here is the patch ..
http://people.apache.org/~funkman/configtest.patch

Comments?


-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1028521 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/tomcat/util/http/mapper/ test/org/apache/tomca

[Tim Funk]

Should we add trim()? (in case the user has a new line or spaces after 
the ,)


this.resourceOnlyServlets.add(servletName.trim());


-Tim

Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1028521&r1=1028520&r2=1028521&view=diff

==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Thu 
Oct 28 22:29:25 2010


On 10/28/2010 6:29 PM, ma...@apache.org wrote:

+@Override
+public void setResourceOnlyServlets(String resourceOnlyServlets) {
+this.resourceOnlyServlets.clear();
+if (resourceOnlyServlets == null ||
+resourceOnlyServlets.length() == 0) {
+return;
+}
+String[] servletNames = resourceOnlyServlets.split(",");
+for (String servletName : servletNames) {
+this.resourceOnlyServlets.add(servletName);
+}
+}


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Parallel deployment

[Tim Funk]

On 10/22/2010 7:39 AM, Mark Thomas wrote:

On 22/10/2010 06:27, Tim Funk wrote:

(1) Since we already have
- effectiveMajorVersion
- effectiveMinorVersion

Is Context.version a "good name" to use? Since the name version is also
used by the servlet spec? Would "revision" be a less confusing name? (Or
webappRevision).


Good point. Maybe webappVersion?


Sounds good.




(2)
[I thought of this as a side effect of reading the patch ...]

Would it be a good idea if Tomcat by default always has a default ROOT
webapp? Then we can guarantee a webapp is always mapped and we can let
that webapp handle the 404 error. This might simplify some of the mapper
and adapter code. So if there is no default webapp - tomcat inserts the
default.


Another good point. Maybe just use the default servlet?



Maybe ... I was of thinking something like a webapp with this (logical) 
definition.




And then (assuming) the default servlet is in
 $CATALINA_HOME/conf/web.xml we then will not need an extra web.xml 
(but it might be convenient to do so in case the defaults in the system 
web.xml have undesirable behaviors)




-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Parallel deployment

[Tim Funk]

Cool. Some notes ...

(1) Since we already have
- effectiveMajorVersion
- effectiveMinorVersion

Is Context.version a "good name" to use? Since the name version is also 
used by the servlet spec? Would "revision" be a less confusing name? (Or 
webappRevision).


(2)
[I thought of this as a side effect of reading the patch ...]

Would it be a good idea if Tomcat by default always has a default ROOT 
webapp? Then we can guarantee a webapp is always mapped and we can let 
that webapp handle the 404 error. This might simplify some of the mapper 
and adapter code. So if there is no default webapp - tomcat inserts the 
default.



-Tim


On 10/21/2010 2:52 PM, Mark Thomas wrote:

[A lot of stuff ... here is a link to it ...]

http://markmail.org/message/h7fjzs52acykjkbj

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.4

[Tim Funk]

> [X] Beta   - go ahead and release as 7.0.4 Beta


-Tim

On 10/15/2010 4:47 AM, Mark Thomas wrote:

The proposed Apache Tomcat 7.0.4 release is now available for voting.

It can be obtained from:
http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/

As with previous votes, I have included a stable option below although
my personal inclination is still to vote beta.

The proposed 7.0.4 release is:

[ ] Broken - do not release
[ ] Beta   - go ahead and release as 7.0.4 Beta
[ ] Alpha  - go ahead and release as 7.0.4 Alpha
[ ] Stable - go ahead and release as 7.0.4 Stable

This vote will run until 10.00 UTC Wednesday 20th October (3 working days).



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1005789 - in /tomcat/trunk/java/org/apache/naming: NamingContext.java NamingContextBindingsEnumeration.java

[Tim Funk]

FYI ...
There was a similar fix applied here but reverted  ...
https://issues.apache.org/bugzilla/show_bug.cgi?id=47512#c4

http://svn.apache.org/viewvc?view=revision&revision=832792
http://svn.apache.org/viewvc?view=revision&revision=832638

-Tim

On 10/8/2010 7:57 AM, ma...@apache.org wrote:

Author: markt
Date: Fri Oct  8 11:57:04 2010
New Revision: 1005789

URL: http://svn.apache.org/viewvc?rev=1005789&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49994
Lookup of JNDI references should return a new object instance each time

Modified:
 tomcat/trunk/java/org/apache/naming/NamingContext.java
 tomcat/trunk/java/org/apache/naming/NamingContextBindingsEnumeration.java

Modified: tomcat/trunk/java/org/apache/naming/NamingContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/NamingContext.java?rev=1005789&r1=1005788&r2=1005789&view=diff
==
--- tomcat/trunk/java/org/apache/naming/NamingContext.java (original)
+++ tomcat/trunk/java/org/apache/naming/NamingContext.java Fri Oct  8 11:57:04 
2010
@@ -797,10 +797,6 @@ public class NamingContext implements Co
  try {
  Object obj = NamingManager.getObjectInstance
  (entry.value, name, this, env);
-if (obj != null) {
-entry.value = obj;
-entry.type = NamingEntry.ENTRY;
-}
  return obj;
  } catch (NamingException e) {
  throw e;

Modified: 
tomcat/trunk/java/org/apache/naming/NamingContextBindingsEnumeration.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/NamingContextBindingsEnumeration.java?rev=1005789&r1=1005788&r2=1005789&view=diff
==
--- tomcat/trunk/java/org/apache/naming/NamingContextBindingsEnumeration.java 
(original)
+++ tomcat/trunk/java/org/apache/naming/NamingContextBindingsEnumeration.java 
Fri Oct  8 11:57:04 2010
@@ -105,13 +105,13 @@ public class NamingContextBindingsEnumer

  private Binding nextElementInternal() throws NamingException {
  NamingEntry entry = iterator.next();
+Object value;

  // If the entry is a reference, resolve it
  if (entry.type == NamingEntry.REFERENCE
  || entry.type == NamingEntry.LINK_REF) {
  try {
-// A lookup will resolve the entry
-ctx.lookup(new CompositeName(entry.name));
+value = ctx.lookup(new CompositeName(entry.name));
  } catch (NamingException e) {
  throw e;
  } catch (Exception e) {
@@ -119,12 +119,11 @@ public class NamingContextBindingsEnumer
  ne.initCause(e);
  throw ne;
  }
+} else {
+value = entry.value;
  }

-return new Binding(entry.name, entry.value.getClass().getName(),
-   entry.value, true);
+return new Binding(entry.name, value.getClass().getName(), value, 
true);
  }
-
-
  }


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Site redesign

[Tim Funk]

Nice work  ...

I think a link needs to be added to report a bug.
http://tomcat.apache.org/bugreport.html


-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JSP:includes parameter passing vulnerability

[Tim Funk]

There is no issue. If there is a typo in the developer code, there is a 
typo in the code. And sometimes typos cause security issues. As a 
general rule, any code which is user provided should validated and 
output escaped.


This is a topic which should be discussed on the user list.

-Tim

On 9/15/2010 2:36 PM, Michael Coates wrote:


Tomcat list,


It seems to me that the method used to request parameters from an
included jsp file should not "fail over" to the URL if the jsp:include
does not provide the parameter.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Draft blog entry for review

[Tim Funk]

Looks good.

It would be really cool to supplement this with a  YouTube video of a 
screen walking through the steps laid out while playing with JConsole.


-Tim

On 9/15/2010 11:07 AM, Mark Thomas wrote:

As I mention recently, JMX is now looking pretty good. I have drafted a
blog entry [1] on this topic that I'd like to publish later this week.
Review / feedback welcome.

Mark

[1]
https://blogs.apache.org/preview/tomcat/?previewEntry=tomcat_7_trunk_and_jmx


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Links to Sun/Oracle on welcome page

[Tim Funk]

+1 To intermediate page on wiki to allow newbies to understand what the 
JCP is


-Tim

On 8/27/2010 6:28 AM, Konstantin Kolinko wrote:


Maybe create a Wiki page to list the relevant specification links? (I
don't have time now, but maybe later).


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Links to Sun/Oracle on welcome page

[Tim Funk]

In that case ... +1 for removing links to 
http://java.sun.com/products/servlets and 
http://java.sun.com/products/jsp (or any http://java.sun.com page)


-Tim


On 8/26/2010 10:04 AM, Mladen Turk wrote:

On 08/26/2010 03:14 PM, Tim Funk wrote:

-1 To removing spec links. We should be linking to the JCP since that
is what Tomcat implements and we WANT developers to know and download
the spec.



We have specs links in the documentation itself.
This is purely removing links from ASF software
to corporate pages.
When you look at those links they are getting more
and more filled with various commercial offerings
from Oracle and less about technology itself.

Why would we advertise that on our front page.


Regards


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Links to Sun/Oracle on welcome page

[Tim Funk]

-1 To removing spec links. We should be linking to the JCP since that is 
what Tomcat implements and we WANT developers to know and download the spec.


It would be nice if we can just put the spec in as part of the docs, but 
IIRC - that is against the licensing terms of the docs. If we could put 
the specs in with the docs - then I'd be +1 for removing the JCP links.


-Tim

On 8/26/2010 6:12 AM, Pid wrote:

On 26/08/2010 07:26, Henri Gomez wrote:



Le 26 août 2010 à 00:44, Konstantin Kolinko  a écrit :


2010/8/25 Mladen Turk:

On 08/25/2010 10:53 AM, Rainer Jung wrote:


What about linking to the Specs? Like

http://jcp.org/aboutJava/communityprocess/final/jsr315/index.html



Still, is it so important that this should be listed on
the front page. We already have those links
(should be updated for Tomcat7 BTW) in our documentation,
so having that on the front page makes no sense to me.

I'd rather have them completely removed.



I am +1 to remove spec links from ROOT/index.html


+1


That is +3 for removal (and a possible -0) by my count, so far.  Anyone
else?



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r988459 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/coyote/http11/filters/ test/org/apache/coyote/http11/ webapps/docs/

[Tim Funk]

log is protected (instead of private) is intentional?

-Tim

On 8/24/2010 6:02 AM, ma...@apache.org wrote:

+
+/**
+ * Logger.
+ */
+protected static org.apache.juli.logging.Log log
+= 
org.apache.juli.logging.LogFactory.getLog(AbstractOutputBuffer.class);


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Update of legal.html to say oracle?

[Tim Funk]

Not sure if this belongs on legal mailing list or not ...

Since Sun is no more and owned by Oracle ... does this page need changed 
to say Oracle?



http://tomcat.apache.org/legal.html

-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Change the name of the default host in server.xml

[Tim Funk]

IIRC, there is no requirement. But from a mapping point of view, the 
name used should match what the browser is sending in the "Host:" field.


Tomcat (iirc) doens't do any lookups based on the name field for Host so 
from that point of view - life in DNS is OK.


But to access the tomcat server - the user needs to type some address 
(name/ip) into the browser.


Where I am going with this is the chance of odd side effect. Let's say 
we choose "default" as the host name. So for some reason (where I can't 
think of a use case) - the admin then types in http://default/ to their 
browser. Their browser does the DNS lookup and goes to whatever DNS 
says. Which is probably not the tomcat instance.


So long story short ... my worry is a stretch, bordering fantasy-land. 
(which is why i am -0 but swayable) But in apache, there used to be 
warnings in various configs about using host names in various places 
instead of IP addresses due to relying on DNS.




-Tim

On 7/15/2010 11:11 AM, Mark Thomas wrote:

On 15/07/2010 15:16, Tim Funk wrote:

-0

Since the host name should be a valid dns name(ok it doesn't need to be
a valid dns name if  is used), choosing a default which doesn't
have a valid dns name may cause woes.


If it does need to be a valid dns name then localhost absolutely makes
sense. Where is that requirement coming from? I can think of anywhere
off the top of my head.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Change the name of the default host in server.xml

[Tim Funk]

-0

Since the host name should be a valid dns name(ok it doesn't need to be 
a valid dns name if  is used), choosing a default which doesn't 
have a valid dns name may cause woes.


But if someone came up with a fantastic alternate default name, then I 
could be swayed.



-Tim

On 7/15/2010 8:51 AM, Mark Thomas wrote:

I'm teaching a Tomcat course today and tomorrow and one of the students
raised the question why is the default host called localhost? The
implied relationship to 127.0.0.1 was causing confusion. That got me
thinking:

1. Is there a better name for the default host

2. If there is, should we change it in Tomcat 7?

Users are familiar with localhost and I am worried that changing it will
cause more problems than it solves. What do folks think? Should we
change the name of the default host to "default", "defaulthost" or
something similar for Tomcat 7 or should we just leave it.

I have an slight preference for changing it to "defaulthost" but only
just. Thoughts? Would this question be better on the users list?


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.0 as beta

[Tim Funk]

> [X] Beta   - go ahead and release as 7.0.0 Beta

-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JIKESPATH in setclasspath.sh

[Tim Funk]

From what I can tell, JIKESPATH is used by jikes which was an 
alternative java compiler. (a long time ago). I believe this is unused 
(even in tomcat6) - so i assume it can probably go.


But I don't have a mac, so its just a wild guess.

-Tim

On 6/8/2010 3:33 PM, Mark Thomas wrote:

On 08/06/2010 18:14, Tim Funk wrote:

Is this needed anymore in setclasspath.sh ?


Works for me with that commented out.

Mark



# OSX hack to CLASSPATH
JIKESPATH=
if [ `uname -s` = "Darwin" ]; then

OSXHACK="/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Classes"

   if [ -d "$OSXHACK" ]; then
 for i in "$OSXHACK"/*.jar; do
   JIKESPATH="$JIKESPATH":"$i"
 done
   fi
fi



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

JIKESPATH in setclasspath.sh

[Tim Funk]

Is this needed anymore in setclasspath.sh ?

# OSX hack to CLASSPATH
JIKESPATH=
if [ `uname -s` = "Darwin" ]; then

OSXHACK="/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Classes"
  if [ -d "$OSXHACK" ]; then
for i in "$OSXHACK"/*.jar; do
  JIKESPATH="$JIKESPATH":"$i"
done
  fi
fi


-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Donation: Want to donate a robust HTTP ProxyServlet to tomcat

[Tim Funk]

-0 (or +1) (Well that was clear ... wasn't it?)

The core consideration is the scope of the Tomcat project. If its to 
deliver a spec compliant servlet/jsp engine. Then I would say (-0 or -1)


If the scope is to increase to also act as a repository for generic 
servlets, then we are in different territory. Yes - the taglib project 
is here, but that decision felt more of a side effect of jakarta 
disappearing and taglibs needing a new home. jdbc-pool resides here out 
of a need to fill a niche dbcp didn't fill. jdbc-pool seems like an 
effort which can be spun out into a different project in the future.


From a tech point of view, I'm not sure how this would be bundled in - 
since the servlet introduces a few new library dependencies.


-Tim

On 6/3/2010 4:39 AM, Sébastien Migniot wrote:

Hi

I'll try to be quick. I'm a french J2EE Architect and author of Streamy,
at http://www.migniot.com/matrix/projects/streamy

I want to *donate the ProxyServlet.java* to tomcat core/extensions,
available at
https://streamy.svn.sourceforge.net/svnroot/streamy/trunk/com.migniot.streamy.Proxy/src/com/migniot/streamy/proxy/ProxyServlet.java



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r950587 - in /tomcat/trunk: java/org/apache/catalina/AccessLog.java java/org/apache/catalina/connector/CoyoteAdapter.java java/org/apache/catalina/valves/AccessLogValve.java webapps/do

[Tim Funk]

Cool - One (very minor) nit ... A safer size might be 500.
A typical User agent string by itself is 100+ characters which will 
easily take the log line over 128 characters.


StringBuilder result = new StringBuilder(128);

-Tim


On 6/2/2010 11:12 AM, ma...@apache.org wrote:

Author: markt
Date: Wed Jun  2 15:12:36 2010
New Revision: 950587

URL: http://svn.apache.org/viewvc?rev=950587&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49099
Hooking the CoyoteAdaptor into the existing AccessLog wasn't as invasive as I 
feared so go that route to log requests rejected by the Adaptor before the 
request/response reaches the AcessLogValve

Added:
 tomcat/trunk/java/org/apache/catalina/AccessLog.java   (with props)
Modified:
 tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
 tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
 tomcat/trunk/webapps/docs/config/valve.xml

Added: tomcat/trunk/java/org/apache/catalina/AccessLog.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/AccessLog.java?rev=950587&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/AccessLog.java (added)
+++ tomcat/trunk/java/org/apache/catalina/AccessLog.java Wed Jun  2 15:12:36 
2010
@@ -0,0 +1,47 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.catalina;
+
+import org.apache.catalina.connector.Request;
+import org.apache.catalina.connector.Response;
+
+
+/**
+ * Intended for use by a {...@link Valve} to indicate that the {...@link Valve}
+ * provides access logging. It is used by the Tomcat internals (the
+ * {...@link org.apache.catalina.connector.CoyoteAdapter} at the time of 
writing)
+ * to identify a Valve that logs access requests so requests that are rejected
+ * earlier in the processing chain can still be added to the access log.
+ * Implementations of this interface should be robust against the provided
+ * {...@link Request} and {...@link Response} objects being null, having null
+ * attributes or any other 'oddness' that may result from attempting to log
+ * a request that was almost certainly rejected because it was mal-formed.
+ */
+public interface AccessLog {
+
+/**
+ * Add the request/response to the access log using the specified 
processing
+ * time.
+ *
+ * @param request   Request (associated with the response) to log
+ * @param response  Response (associated with the request) to log
+ * @param time  Time taken to process the request/response in
+ *  milliseconds (use 0 if not known)
+ */
+public void log(Request request, Response response, long time);
+}

Propchange: tomcat/trunk/java/org/apache/catalina/AccessLog.java
--
 svn:eol-style = native




Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=950587&r1=950586&r2=950587&view=diff



+public void log(Request request, Response response, long time) {
+if (logElements == null || condition != null
+&&  null != request.getRequest().getAttribute(condition)) {
+return;
+}
+
+Date date = getDate();
+StringBuilder result = new StringBuilder(128);
+
+for (int i = 0; i<  logElements.length; i++) {
+logElements[i].addElement(result, date, request, response, time);
+}
+
+log(result.toString());
+}


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CSRF prevention filter and Tomcat 5/6

[Tim Funk]

+1 to E

-Tim

On 5/10/2010 11:47 AM, Mark Thomas wrote:

On 10/05/2010 13:25, Konstantin Kolinko wrote:

Thoughts?



It is possible to combine A+C:

E. Use a different name for the new role that allows access to GUI
interface only,
"manager-gui", as well as new "manager-script", "manager-jmx",
"manager-status".

We can even rename "manager" -> "manager-gui" in Tomcat 7.

The "manager" role is preserved as is, but is documented as
"deprecated" and is no longer recommended for use.


I like it. Neat solution.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: CSRF prevention filter and Tomcat 5/6

[Tim Funk]

D (and possibly B)

In the case of B - instead of commenting out - wrap a filter around it 
that has default behavior of not being enabled.


So it would look like this:
boolean allowTextInterface = false;
init(FilterConfig) {
  String s=System.getProperty("manager.allowTextInterface");
  allowTextInterface = "Y".equals(s);
}
doFilter(req,resp) {
  if (!allowTextInterface) {
chain.doFilter(req,resp);
  } else {
response.sendError(403);
  }
}

The advantage of a system property is admins don't need to change 
web.xml. They only need to add a system property on startup, which 
something all admins need to do due to GC flags etc. Then for those in 
the know - they can always rip out the filter from web.xml (which is D 
anyways)



-Tim

On 5/7/2010 1:50 PM, Mark Thomas wrote:

I'm trying to decide the best way to back-port the configuration of this
to the (Host) Manager app in Tomcat 5 & 6.

The requirements are:
- not to break anything that currently works
- enable CSRF for the HTML interface
- the same user cannot have access to the HTML and text interfaces for
the filter to be effective.

I can't see a way to meet all of these.

The options I am considering are:
A: change the role required to access the text interface to manager-text
- consistent with Tomcat 7
- will break tools currently using the manager role

B: comment out the mapping for the test interface
- will break tools currently using the text interface

C: change the role required to access the HTML interface
- not consistent with Tomcat 7
- will break user access to the Manager GUI

D: Don't enable the filter by default but provide instructions on what
to do if you do want to enable it in the docs. Something along the lines
of:
- uncomment the Filter and filter mapping
- change the role used for the text and jmx interfaces (to match the new
names in Tomcat 7)


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Access logging for requests rejected by CoyoteAdaptor

[Tim Funk]

I think I am changing my mind, I am leaning towards 1.

There are cases where I think we can use the regular access log (where I 
like solution 2).


But with solution 1. You can also log "oddness". Connections which 
timeout, or never present a request, etc. So the format of the 
CoyoteAdaptor log more textual/message oriented. (That is a new format)



-Tim

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Comet API incompatibility between TC 6 and TC 7

[Tim Funk]

Would it be possible to just create an optional package that has all the 
old class names and their implementation is just an extends of the new 
version? (As well as being marked deprecated)



-Tim


On 4/30/2010 2:51 AM, Konstantin Kolinko wrote:

There is a difference in Comet API that will require all TC6 Comet applications
to be patched and recompiled before deploying them to TC7:

Comet classes were moved from "org.apache.catalina" to
"org.apache.catalina.comet".

What do you think, is this change acceptable for us?

IIRC, the cause behind this is
https://issues.apache.org/bugzilla/show_bug.cgi?id=48218
-- to have access to Comet classes when running with a SecurityManager one has
to grant access to "org.apache.catalina" package, which exposes the server API.

If we go on with this, a notice has to be added to
http://tomcat.apache.org/migration.html



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Access logging for requests rejected by CoyoteAdaptor

[Tim Funk]

I like case 2.

In the case of the malformed request. We might not be able to determine 
the host or the path (and therefore the appropriate webapp (or host))


In the common case (admin), I would hope that there is an AccessLog at 
the EngineLevel. So we might be able to do the following ...

- Create a new Interface called AccessLog (like Mark's suggestion)
- It has one method: log(request, response)
- CoyoteAdapter Can trap the conditions where it doesn't send the 
request down the pipeline.
- Instead of not logging the requests, it will find any Valves with 
AccessLog interface and call log(...)


With any luck, the request, response pair will still be complete enough 
to ensure that the access loggers don't reach any weird conditions. 
[Unexpected NPE, etc]


I think the hardest part of the above is cleanly changing CoyoteAdapter 
since I see multiple spots where logging is skipped.


-Tim

On 4/28/2010 8:14 PM, Mark Thomas wrote:

2. Provide hooks in access log valves to allow CoyoteAdaptor to log
these rejections via the access log valve
Pros: All access logs in one place
Could be used by other components
Cons: More complex solution. CoyoteAdaptor would have to navigate
container hierarchy to find access log. Probably need a new AccessLog
interface to enable CoyoteAdaptor to work with multiple implementations.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r937975 - /tomcat/trunk/java/org/apache/catalina/core/StandardContext.java

[Tim Funk]

Got it

thanks

-Tim

On 4/26/2010 6:36 AM, Mark Thomas wrote:

On 26/04/2010 11:33, Tim Funk wrote:

I'm feeling stupid at the moment. (Or need more coffee) But why do the
parenthesis make a difference? (Since only addition/subtraction is done
and no multiplication - I can't tell why this fixes it)


100 - 10 + 1 = 91
100 - (10 + 1) = 89


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r937975 - /tomcat/trunk/java/org/apache/catalina/core/StandardContext.java

[Tim Funk]

I'm feeling stupid at the moment. (Or need more coffee) But why do the 
parenthesis make a difference? (Since only addition/subtraction is done 
and no multiplication - I can't tell why this fixes it)


-Tim

On 4/26/2010 5:17 AM, ma...@apache.org wrote:

Author: markt
Date: Mon Apr 26 09:17:46 2010
New Revision: 937975

URL: http://svn.apache.org/viewvc?rev=937975&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49184
Prevent ArrayIndexOutOfBoundsException
Patch provided by Pid

Modified:
 tomcat/trunk/java/org/apache/catalina/core/StandardContext.java

Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=937975&r1=937974&r2=937975&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Mon Apr 26 
09:17:46 2010
@@ -2627,7 +2627,7 @@ public class StandardContext
  System.arraycopy(filterMaps, 0, results, 0, filterMapInsertPoint);
  results[filterMapInsertPoint] = filterMap;
  System.arraycopy(filterMaps, filterMapInsertPoint, results,
-filterMaps.length - filterMapInsertPoint + 1,
+filterMaps.length - (filterMapInsertPoint + 1),
  filterMaps.length - filterMapInsertPoint);

  filterMapInsertPoint++;


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r933165 - /tomcat/trunk/java/org/apache/catalina/tribes/io/ChannelData.java

[Tim Funk]

This seems like an odd thing to make a constant. (Is something else 
setting this or was there an intention for this to be set? Especially 
since it is used only once in this file)


-Tim

On 4/12/2010 5:35 AM, ma...@apache.org wrote:

Author: markt
Date: Mon Apr 12 09:35:52 2010
New Revision: 933165

URL: http://svn.apache.org/viewvc?rev=933165&view=rev
Log:
Make public constant final

Modified:
 tomcat/trunk/java/org/apache/catalina/tribes/io/ChannelData.java

Modified: tomcat/trunk/java/org/apache/catalina/tribes/io/ChannelData.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/io/ChannelData.java?rev=933165&r1=933164&r2=933165&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/io/ChannelData.java (original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/io/ChannelData.java Mon Apr 12 
09:35:52 2010
@@ -38,7 +38,7 @@ import java.sql.Timestamp;
  public class ChannelData implements ChannelMessage {
  public static final ChannelData[] EMPTY_DATA_ARRAY = new ChannelData[0];

-public static boolean USE_SECURE_RANDOM_FOR_UUID = false;
+public static final boolean USE_SECURE_RANDOM_FOR_UUID = false;

  /**
   * The options this message was sent with


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Chunked encoding should be used also when not using keepalive

[Tim Funk]

OMG ... That is the argument made in the original request. (I need to 
re-read and think more before response) I'm really sorry for the noise, 
worst april 1 ever. Please put me on /ignore for the rest of the day.


My opinion on the change is +0. (The change has some penalties, but the 
net effect might be good)



-Tim

On 4/1/2010 6:54 AM, Tim Funk wrote:

A good argument to add is chunked encoding would that it gives the
client the best guess on whether the entire response was returned (by
receiving the last full chunk). But that argument is weak.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Chunked encoding should be used also when not using keepalive

[Tim Funk]

Agree with Remy. If 'connection: close' is sent by the client, then 
tomcat needs to close the connection on the end of the response. So 
sending the results via chunked encoding is extra overhead which is not 
needed.


A good argument to add is chunked encoding would that it gives the 
client the best guess on whether the entire response was returned (by 
receiving the last full chunk). But that argument is weak.


-Tim

On 4/1/2010 6:39 AM, Remy Maucherat wrote:

On Thu, 2010-04-01 at 11:28 +0100, Mark Thomas wrote:

On 01/04/2010 11:02, Óscar Frías Barranco wrote:

What do you think ?


Seems reasonable but I'd like to hear from some of the other committers
before making any changes.

If the change is made, it needs to be made for all connectors, not just
the BIO connector.


It is not needed in the spec and is more expensive, as closing the
connection is one of the valid content delimitation methods.

His reverse proxy argument is probably the worst one: "connection:
close" does not land in the response by accident, it is added for good
reason. This is just begging for hacks at this point.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Chunked encoding should be used also when not using keepalive

[Tim Funk]

Wait a sec ... not enough coffee. I might have answered a totally 
different question (and incorrectly too)


-Tim

On 4/1/2010 6:42 AM, Tim Funk wrote:

Doing this would be bad. When serving JSP's (or anything dynamic greater
than the buffer size) - the content length is not sent to the client. So
when the end of the request is sent - there is no signal to the client
to let them know the request is over and they can start a new request
over the same connection.

With chunked encoded - we can get away with no content length header
because the each chunk as the length.

-Tim

On 4/1/2010 6:02 AM, Óscar Frías Barranco wrote:

Hello.

Currently Tomcat HTTP 1.1 Connector disables the use of chunked
encoding if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Chunked encoding should be used also when not using keepalive

[Tim Funk]

Doing this would be bad. When serving JSP's (or anything dynamic greater 
than the buffer size) - the content length is not sent to the client. So 
when the end of the request is sent - there is no signal to the client 
to let them know the request is over and they can start a new request 
over the same connection.


With chunked encoded - we can get away with no content length header 
because the each chunk as the length.


-Tim

On 4/1/2010 6:02 AM, Óscar Frías Barranco wrote:

Hello.

Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
keepalive is not used.  This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.

Chunked transfer-encoding is an alternative to content-length, for use when
the content-length cannot initially be determined.  While it is mandatory to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a client
to distinguish a connection abort from a complete response in order to avoid
storing truncated data.

Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx).  The lack of content-length and
chunked encoding prevents the proxy from keeping client connections alive.
The "connection: close" sent by the proxy to the server only indicates that
the proxy will send just one request to the server, not that it does not
care about the response length.  The same is true when that proxy caches.
Without any content-length nor chunked encoding, the cache could store and
distribute truncated response believing they are complete, while this would
not happen with chunked encoding because the cache will be able to know it
has not seen the end of the response.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [ANN] New Tomcat Committer: Keiichi Fujino (kfujino)

[Tim Funk]

congratulations!

-Tim

On 3/31/2010 3:29 PM, Filip Hanik - Dev Lists wrote:

On behalf of the Tomcat committers I am pleased to announce that Keiichi
Fujino (kfujino) has been voted in as a new Tomcat committer.

Please join me in welcoming him.



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org