Re: [PATCH] Performance Problems in Coyote Chunking

2003-09-12 Thread Marc Slemko
On Fri, 12 Sep 2003, Remy Maucherat wrote:

 Steve Appling wrote:

  The following patch combines the 3 packets that were generated for each
  chunk into just one packet.  There are more optimizations elsewhere - I'll
  keep looking.
 
  Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27
  src.

 After testing and benching, implementing buffering at the lower layer is
 much better, as it avoids introducing complexity in all the levels of
 processing, and is more powerful. The performance impact of the new
 behavior is minimal (using a worst case scenario of a static file, the
 difference is about 2-3%).
 I believe the updated implementation will meet your needs.

 What's the most optimal packet size overall, BTW ? 1500 ?

there is nothing inherently relating chunk sizes in chunked output to
packet sizes.

From the network perspective, you want some reasonably sized (at a minimum
8k; that is what Apache uses)  buffer between the code generating content
and the network, and you never want to explicitly flush that to the
network unless you are actually at the end of a response.

You have no idea what the MTU on the network is, and your code shouldn't
care.  It should just present the data to the network stack in as big of a
buffer as practical (ie. in one write call), and let it worry about that.

You don't want to be creating HTTP chunks arbitrarily, you only want to do
that when you are writing a buffer to the network layer.  Normally one
HTTP chunk should span multiple packets when the network layer puts it on
the wire.

In an ideal world, you could just use a GatheringByteChannel to present
the chunk header and the chunk to the network layer at the same time (ie.
ala writev()), but compatibility issues are a problem for now.

In addition, when serving truly static content where you can determine the
content length in advance (eg. serving an image from disk), avoiding
chunking alltogether and just setting a content length is definitely
preferred.

At the end, if you are sending a response with 300 bytes of headers and
800 bytes of content, the content should be in at most one chunk and the
headers and content should end up on the network in the same packet,
assuming a MTU of at least 1500.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: URI Space and smarter hand off between Apache/Tomcat

2003-07-17 Thread Marc Slemko
On Thu, 17 Jul 2003, P. Brewer wrote:

 I found the following thread from a year ago:

 http://marc.theaimsgroup.com/?l=tomcat-devm=102815260317741w=2\

 Basiclly discussing a JkNotMount for excluding images and other
 static content from being passed to Tomcat.  I can't tell that
 anythin was done.

 Was it shot down for a technical reason?  Just didn't get implmented?
 Or is implemented and not documented?  I can help with C code, but
 probably not much help with Java code.

You would probably be better off to just make mod_jk* properly support
Apache (and other webserver) configuration directives such as Directory
and Files, then use them to control what gets passed on to tomcat.

Having mod_jk trying to do parsing based on filenames on disk is a
very bad idea for performance and security reasons, especially on
win32 platforms.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [5.0] [PROPOSAL] Make output buffer size limit configurable

2003-07-14 Thread Marc Slemko
On Mon, 14 Jul 2003, Jan Luehe wrote:

 It can also be useful if you have a client that doesn't support chunked
 encoding - which is probably true for a _lot_ of scripting tools.
 If there is any other way to have the response not use chunked encoding,
 then I agree this is not needed.
 
 Do we still support HTTP/1.0 or some request header to disable the
 
  encoding?
 
 
  AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical
  to Apache/httpd.

 I noticed that if I send a request specifying HTTP/1.0 as the protocol
 version, and the response exceeds the output buffer, TC returns an
 HTTP/1.1 response with neither a Content-Length nor a
 Transfer-Encoding: chunked header.

 I would have expected it to include a Content-Length header. Would you
 agree?

It, umh, can't do that for dynamic content without buffering the
whole response since it doesn't know how long it is.

Hence the main reason for chunked encoding and the requirement
HTTP/1.1 clients support it.

Any HTTP/1.1 client must support chunked encoding, if not then it is
broken and really don't need to be taken into account.  If someone
doesn't want to support chunked encoding, they shouldn't be making
HTTP/1.1 requests.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/commonjk_uri_worker_map.c jk_uri_worker_map.h

2003-06-27 Thread Marc Slemko
On Thu, 27 Jun 2003 [EMAIL PROTECTED] wrote:

 billbarker2003/06/26 19:54:18

   Modified:jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
   Log:
   Fix problem with URLs that contain //.

   This is essentially what Apache/httpd does in location_walk.

Make sure you realize that, especially on windows, this is unlikely to
be sufficient to fix this class of problems unless there is other code
somewhere that I didn't see when I checked.

What happens, for example, if you have a directory /directory/ that
also has a 8.3 name direct~1 and access the direct~1 form of the name?
What prevents the rule mapping /directory/*.jsp to tomcat from being
bypassed?

This is one of the reasons why the Apache documentation tells you
never to use a Location section to protect or control access to
the filesystem, but instead to use a Directory section.  Due to filename
variance there are many different filenames, and hence URLs, that
can be used to access the same actual file bypassing the protection
(in this case mapping).  This requires the filename be canonicalized
for comparisons, which is partly done in directory_walk() in Apache.

Certainly, doing this right is complex.  But that is one of the
exact reasons I run Apache in front of Tomcat and why I want Tomcat
and the connectors to it to have the smallest possible duplicate
codepath.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: cvs commit: jakarta-tomcat-connectors/jk/native/commonjk_uri_worker_map.c jk_uri_worker_map.h

2003-06-27 Thread Marc Slemko
On Fri, 27 Jun 2003, Henri Gomez wrote:

 If you want to be very secure, you sue Apache in front of Tomcat,
 and tomcats located on other machines.

 In such case you use ajp13, and with this configuration, I DIDN'T HAVE
 ANY PROBLEM with '//' since it's handle by tomcat (tested with 3.3.1a),
 since Apache web server couldn't read NON LOCAL DATAS isn't it ?

 The general rule for security is to make use of JkMount to ROOT :

 JkMount /webappx/servlet/ ajpworker
 JkMount /webappx/*.jspajpworker

 Or JkMount /webappx/* ajpworker


 And in your jsp/servlet/..., you put ref to Apache handled element,
 like images, html in /images, /text, /, which are NOT in the
 /webappx scope and so will be server by Apache.

Thanks for the suggestion, it certainly is one option that can work
for some people in some situations.  However, it isn't a very good
general purpose solution for a variety of reasons, and certainly should
not be necessary.

 You seems very aware of Apache Internals and I reiterate our proposal
 (at least Remy and I), to provide fixes.

Enough with the attitude.  I'm just trying to point out specific
instances where things are not or may not be handled properly so
perhaps someone can fix them if they so desire.  I am making no
demands that anyone jump up and do so, nor blaming anyone for
anything, but simply pointing out what is broken and why.

Is it reallly the case around here that people don't want to hear about
specifics of bugs and security holes that impact a large percent of users
unless a patch is provided?

All I am doing is trying to make sure people are aware that the particular
case of a double '/' is only a subset of the more general issue that has
to be dealt with.  Your if you don't like it go fix it yourself
responses are not appreciated nor are they condusive to making people feel
welcome or in any mood to contribute anything.  I already said I don't
have time to do that right now, but will likely do so in the future if it
is still broken by the time I need it to work right.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk multiple slashes reveals jsp code

2003-06-26 Thread Marc Slemko
On Thu, 26 Jun 2003, Henri Gomez wrote:

 Could we stop useless critics and flams and be more positives.

I'm sorry that you think it is useless to point out the specific areas
where mod_jk and mod_jk2 are doing things wrong.

 It's open source, and if you have objections, you're welcome to provide
 fixes.

To be honest, that isn't too appealing given the sad state of all
the different connectors available and the extremely poor state of
documentation about what is what and how things are supposed to
work.  But that is irrelevant, and doesn't change the validity of pointing
out what things are problems and why.

What is the release plan for mod_jk2?  Is there any plan for making it
production quality?  There doesn't seem to be much happening with it.
Is one better served to work on mod_jk instead and give up on mod_jk2?


 Never forget that mod_jk WAS DESIGNED to be cross web server compatible
 and that's why some of the Apache functions are not used.

mod_jk is the Apache specific module.  The fact that there are other
modules using some shared code that are specific to other webservers
doesn't change anything.

Web server specific plugins are the things that should tie tomcat in
with the way the particular webserver works.

It is quite sad to see how much worse webserver plugins have gotten
since the days of mod_jserv.

 BTW, on the Tomcat side, there is some URI checks since this problem
 could also appears when using the built-in http connector.

 In the actual case the problem seems to be that Apache handle the jsp
 directly since it didn't forward it to tomcat (probably because apache
 and tomcat run on the same machine)

The problem isn't that Apache doesn't forward it, the problem is that
mod_jk doesn't forward it because it reimplements things that Apache
can do for it a lot better and in a way that ensures it is compatible
with everything else happening in the webserver.  The same applies to
other webservers.  The mapping of what things should be passed to
tomcat and what things shouldn't is a security critical area that
can not be glossed over with a ahh, we'll just make up our own way of
doing things since it means we don't have to bother with the webserver.
It is a plugin for the webserver, you have to bother with how the webserver
works.

It was a bad design decision to take the shortcut of trying to embed
all the configuration within shared code and reuse it for every webserver.

By describing the problems, I'm hoping that someone who does have the
time right now can actually make one of the multitude of Apache -- tomcat
connectors into something production quality without gaping security,
performance, and stability issues.  If not, then it will have to wait
until I am at a point in my day job where we need to be deploying our
applications and they need to actually work right and I'll worry about
it then.

Oh, for whoever is trying to actually make mod_jk work right... you may
be able to do a SetHandler jakarta-servlet inside a Files section
in a Directory section, not sure if it supports it properly or not, although
that doesn't let you specify a specific worker.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk multiple slashes reveals jsp code

2003-06-25 Thread Marc Slemko
On Wed, 25 Jun 2003, Palle Girgensohn wrote:

 setup:

 FreeBSD 4.8-RELEASE, apache 1.3.27 w/ mod-ssl 2.8.14, mod_jk 1.2.3 and
 1.2.4. Tomcat version is irrelevant since the request never leaves apache,
 but anyway, it is tomcat 3.3.1a.

 JkMount /pp/system/*jsp

 [Wed Jun 25 01:32:48 2003]  [jk_uri_worker_map.c (460)]: Into
 jk_uri_worker_map_t::map_uri_to_worker
 [Wed Jun 25 01:32:48 2003]  [jk_uri_worker_map.c (477)]: Attempting to map
 URI '/pp/entrance/login.jsp'
 [Wed Jun 25 01:32:48 2003]  [jk_uri_worker_map.c (558)]:
 jk_uri_worker_map_t::map_uri_to_worker, Found a suffix match tomcat - *.jsp
 [Wed Jun 25 01:33:14 2003]  [jk_uri_worker_map.c (460)]: Into
 jk_uri_worker_map_t::map_uri_to_worker
 [Wed Jun 25 01:33:14 2003]  [jk_uri_worker_map.c (477)]: Attempting to map
 URI '//pp/entrance/login.jsp'
 [Wed Jun 25 01:33:14 2003]  [jk_uri_worker_map.c (599)]:
 jk_uri_worker_map_t::map_uri_to_worker, done without a match

 map_uri_to_worker just makes an exact match, in my case //pp/system
 against /pp/system/, actually on line 485:

 if(0 == strncmp(uwr-context,
 uri,
 uwr-ctxt_len)) {

 double slashes after /pp/system/ are OK, they will be sent on to tomcat,
 which has code to handle this.

This reflects a design problem in mod_jk.  Instead of using Apache's
support for Directory sections and handlers, it attempts to
reimplement it on its own.  This is one example of where it doesn't
work and exposes a security issue.  There are a lot of other examples,
especially on windows, where there is a lot of filename variance.

When you are protecting (in this case, by forwarding to something
else to handle them) files, you will expose yourself to a wide
variety of security holes if you attempt to do so based on URI
instead of on the canonical version of the path.

There is a related problem in mod_jk2 that I ran into, which results
in breaking any attempt to use a DirectoryIndex setting with
index.jsp or some such in it.  If you configure mod_jk2 to
handle *.jsp, it assumes that if you get a request for foo.jsp then
tomcat should handle it even if foo.jsp doesn't exist, so it sends the
request to tomcat even if there is no such file.  Same underlying
cause: trying to dispatch based on parsing the URI instead of
using Apache's built in support for doing such things in a more
graceful and robust manner.  Even more horrible is the fact that
mod_jk2 lets you enclose things in Location sections such as:

Location /*.jsp
  JkUriSet group ajp13:worker1
/Location

...only it uses some horrible hacked up kludge to actually
parse the argument to the Location itself.  Even though this
is a Location directive, because of mod_jk2's very odd
design the arguments are interpreted completely differently
from how Apache does, which leads to all sorts of chaos.

If I recall correctly, and I haven't checked for a few months, I
think there are some comments in the mod_jk2 code indicating that
support for using it as an Apache handler was removed because the
person hacking on it didn't understand why it is necessary.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]