Re: Tomcat 7 cannot get ciphers with SHA256 or SHA384
On 26/05/2014, at 6:58 pm, Sverre Moe sverre@gmail.com wrote: Documentation aside, none of these cipher-suites are supported in Oracle Java 7. The AES_CBC ciphers I had there are supported in Java 7. I have already concluded as much regarding the AES_x_GCM. Using Java 8 one have access to these higher GCM ciphers, but only very few obscure browsers supports them. Therefore neither AES_256_GCM nor SHA384 can be used yet. Latest versions of Firefox and Chrome (and others I suspect) use GCM ciphers (gmail seems to prefer them for example). Also because of the the JSSE cipher ordering it will always choose AES_x_CBC instead over AES_x_GCM if both are in the Connector cipher list. See table: Default Enabled Cipher Suites http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider Same ordering you get from getDefaultCipherSuites(); You don’t have to accept the default ciphers, or ordering. Check the docs for the HTTP connector to see how to configure this. tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 cannot get ciphers with SHA256 or SHA384
On 27/05/2014, at 6:09 am, Christopher Schultz ch...@christopherschultz.net wrote: snip If you run the code I referenced elsewhere in this thread, you'll see that some of the components are available, just not in the combinations you have above: $ java -showversion -classpath build/ SSLInfo | grep '\(256\|384\)' java version 1.7.0_55 Java(TM) SE Runtime Environment (build 1.7.0_55-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode) Supported SSL Protocols: TLSv1 (SunJSSE) TLSv1.1 (SunJSSE) TLSv1.2 (SunJSSE) Default Cipher Name * TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 * TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 * TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 * TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_NULL_SHA256 So, you can get ECDHE_(ECDSA|RSA)_AES, but not with a 256-bit cipher. You can get a 128-bit cipher and a 256-bit hash, but not higher-bit hash functions. Oracle Java 7 has no GCM support (AIX does I think, but from memory the cipher suite names are different), and some of the cipher-suites don’t exist (see below). GCM was originally targeted for JDK 7 (which is why the cipher suite names and AEAD APIs in the JCE are there) but the implementation didn’t show up until JDK 8. I find no ciphers with 384-bit hashes in Oracle Java 8, but there are 256-bit ones -- at least in the Mac OS X build: Do you have the unrestricted crypto policy files installed? Without those, 128 bit security ciphers (== 256 bit hashes) are suppressed. Cipher suites with SHA384 are definitely available on both JDK 7 and JDK 8 on OS X. I’m using the interactive mode of https://github.com/timw/groktls to dump these. tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7 cannot get ciphers with SHA256 or SHA384
On 21/05/2014, at 10:21 pm, Sverre Moe sverre@gmail.com wrote: snip ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA265,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256 / Documentation aside, none of these cipher-suites are supported in Oracle Java 7. Oracle Java 7 has no GCM support (AIX does I think, but from memory the cipher suite names are different), and some of the cipher-suites don’t exist (see below). GCM was originally targeted for JDK 7 (which is why the cipher suite names and AEAD APIs in the JCE are there) but the implementation didn’t show up until JDK 8. I have tried running Tomcat with Java 7 and Java 8. Both of these should support CBC_SHA256 and CBC_SHA384, but only Java 8 supports GCM_SHA384. I have downloaded the Java cryptographic extensions policy files for both Java 7 and Java 8. The only way I get a connection is when I add the following ciphers: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA According to the specification all these ciphers are correct names: http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#ciphersuites This is not true for TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA265 or TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256 in Java 7 or 8 (only SHA/ SHA384 or AES_128 variants of these are listed in the docs and reported by the JRE). i.e. for whatever reason, SHA384 and SHA are coupled with AES_256, and SHA256 and SHA are coupled with AES_128. The email trail Christopher linked should help you discover what’s available on the system you’re running on. cheers tim For the record, these are the ECDHE cipher suites supported in Oracle Java 7, excluding those that use SHA(1): Cipher Kx Au EncMode Key Str MacSize Unsafe TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDHEECDSAAESCBC 256 (256) SHA384 384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384ECDHERSA AESCBC 256 (256) SHA384 384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ECDHEECDSAAESCBC 128 (128) SHA256 256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256ECDHERSA AESCBC 128 (128) SHA256 256 Oracle Java 8 adds the following ECDHE + GCM cipher suites (again not including SHA(1)) to the list above: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDHEECDSAAESGCM 256 (256) SHA384 384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDHEECDSAAESGCM 128 (128) SHA256 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384ECDHERSA AESGCM 256 (256) SHA384 384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256ECDHERSA AESGCM 128 (128) SHA256 256 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not accept connections from Safari on iPad vs an SSL connector with JSSE ciphers
On Tue, Feb 19, 2013 at 10:59 AM, Giuseppe Sacco giuse...@eppesuigoccas.homedns.org wrote: [...] I listed all providers here: http://centrum.lixper.it/~giuseppe/ipad-tomcat-list-ciphers-no-bouncycastle.html as you may see, a few of them are TLS_RSA and TLS_DHE: * TLS_RSA_WITH_AES_128_CBC_SHA * TLS_RSA_WITH_AES_256_CBC_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA * TLS_DHE_DSS_WITH_AES_256_CBC_SHA * TLS_DHE_RSA_WITH_AES_128_CBC_SHA * TLS_DHE_RSA_WITH_AES_256_CBC_SHA They are also listed as default ciphers, so -- if I understood what default means -- they should not be enabled explicitly. They overlap with those client ciphers: TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA Is there any possibility that some of those server ciphers are disabled because of the algorithm used in the server certificate? Its signature algorithm is SHA1withDSA. I created it with this command line: keytool -genkeypair -alias tomcat -keystore ~tomcat6/.keystore Yes. If the server keys are DSA, then only cipher suites using DSS/*DSA will be negotiated. In this case, the only DSS cipher suite that your client appears to support is TLS_DHE_DSS_WITH_NULL_SHA, which isn't supported by Java 6 or 7. A side note: is it possibile to put tomcat behind a web server and make the latter encrypt in SSL? This would imply that communication between the web server and tomcat would be in clear, but how do I create the connector proxy* information? I may specify proxyName and proxyPort, but I cannot specify proxyProtocol. Is this right? tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA The BIO connector in = 7.0.35 silently reverts to the JVM default ciphers (and sslEnabledProtocols) if none of the specified options are supported by the SSL implemenation. I've changed this in 7.0.36+ [1] to not do this (I've had customers bitten by the same issue when running on AIX, since IBM change the prefix on all the cipher suites from TLS_ to SSL_). [1]: https://issues.apache.org/bugzilla/show_bug.cgi?id=54406 cheers tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
It looks like this is a regression in 1.2.31 - the socket shutdown code that drained the response message from the AJP socket before closing it was mis-counting the bytes read, causing a CPU busy loop until it hit a 30 second cap on lingering byte reads. I've committed a fix for 1.2.32 and also capped the amount of data that the socket shutdown will read to 32k, and the total time to drain the socket to 2s. cheers tim On Mon, May 16, 2011 at 1:09 PM, verlag.preis...@t-online.de verlag.preis...@t-online.de wrote: Hi Tim, This sounds like https://issues.apache.org/bugzilla/show_bug.cgi?id=50839 If you can capture a TRACE level log form the Tomcat Connector (configure in isapi_redirect.properties) and attach it to the bug, I'll take a look. cheers tim Thanks! I will attach a Trace level log from the Redirector there. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Canceling Download on IIS7 with ISAPI Redirector 1.2.31 causes 100% CPU usage
This sounds like https://issues.apache.org/bugzilla/show_bug.cgi?id=50839
If you can capture a TRACE level log form the Tomcat Connector
(configure in isapi_redirect.properties) and attach it to the bug,
I'll take a look.
cheers
tim
On Sun, May 15, 2011 at 1:20 AM, eurotrans-Verlag
verlag.preis...@t-online.de wrote:
Hello everybody,
I stumbled upon a strange problem with the ISAPI Redirector 1.2.31 on
Windows Server 2008 SP2 (32 bit) with IIS 7.0. The problem is, that when a
Servlet is generating lots of data (e.g. 200 MB) and a user downloads it
over the Isapi Redirector/IIS7, and cancels the download, the IIS Worker
process (w3wp.exe) will have 100% CPU usage for about 30 seconds. However if
the download is completed normally (not canceled), everything is fine and
the CPU usage will not go up that far.
The exact Components used are:
Windows Server 2008 SP2 (32 bit) with IIS 7.0,
Sun JDK 1.6.0_25,
Tomcat 7.0.14,
ISAPI Redirector 1.2.31.
I could reproduce the problem with a clean install of these components.
To reproduce:
1. Install Tomcat and the ISAPI Redirector on a Windows Server 2008 SP2 IIS
7.0 system, as described in the Tomcat Connectors Documentation
(The problem occurs with both settings of enable_chunked_encoding, true
and false).
2. Create a Servlet or JSP that produces some huge amount of random data,
for example:
@WebServlet(/DownloadServlet)
public class DownloadServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
response.setContentType(application/x-msdownload);
OutputStream out = response.getOutputStream();
Random r = new Random();
byte[] content = new byte[1024];
for (int i = 0; i content.length; i++)
content[i] = (byte) (r.nextFloat() * 256);
for (int i = 0; i 20; i++)
out.write(content);
out.close();
}
}
3. Request the Servlet or JSP through the IIS port with a browser. After
some seconds, cancel the download.
4. One thread of the IIS Worker Process (w3wp.exe) will have 100% CPU usage
for some time (about 30 seconds), before it normalizes to 0%.
Note that is does not happen every time. Sometimes you will have to repeat
starting and canceling the download until the problem occurs.
5. In the ISAPI log, following lines are logged (log_level=info):
[Sat May 14 14:48:55.654 2011] [3508:3560] [error]
isapi_write_client::jk_isapi_plugin.c (1210): WriteClient failed with 995
(0x03e3)
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_process_callback::jk_ajp_common.c (1885): Writing to client aborted or
client network problems
[Sat May 14 14:48:55.654 2011] [3508:3560] [info]
ajp_service::jk_ajp_common.c (2543): (worker1) sending request to tomcat
failed (unrecoverable), because of client write error (attempt=1)
[Sat May 14 14:48:55.669 2011] [3508:3560] [info]
HttpExtensionProc::jk_isapi_plugin.c (2217): service() failed because client
aborted connection
These lines are logged immediately after the client cancels the connection
(not after the CPU usage of w3wp.exe goes down).
The worker process continues normally after the CPU usage went down.
However, if one would do this repeatedly, it could enable DoS attacks,
couldn't it?
What would cause these excessive CPU usages of the IIS worker process when
the user cancels the download?
Thanks for your help.
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Windows Authentication: Issue 49318 vs 47679
On Mon, Mar 28, 2011 at 7:26 AM, Stefan Mayr ste...@mayr-stefan.de wrote: Hello everybody, as many others before we wanted to do single-sign-on for intranet web applications using integrated windows authentication (negotiate because IE sometimes tries NTLM instead of using plain kerberos - breaking all our kerberos-only experiments). We thought that IIS would be the best choice for integrated windows authentication and we could pass the user via AJP (using mod_jk) to our tomcat instances. Our setup: - Windows 2008 R2 using IIS 7.5 (64bit) - mod_jk 1.2.31 - Oracle Java 1.6 U24 - Tomcat 6.0.32 At first glance using tomcatAuthentication=false worked as expected. We got the remote user and started deploying an application. End of happiness - the application complained about a missing user-agent. That header was not passed to tomcat when authentication was enabled on IIS. Some research revealed Bug 47679 - Not all headers get passed to Tomcat server from isapi_redirect.dll (https://issues.apache.org/bugzilla/show_bug.cgi?id=47679) Today I've found Bug 49318 - add a Negotiate (Kerberos/NTLM) authenticator / integrate Waffle (https://issues.apache.org/bugzilla/show_bug.cgi?id=49318). The last comment links a new Windows Authentication How-To from Mark Thomas. Looks like we have already tried almost all proposed solutions: - IIS + mod_jk: tried but stuck in Bug 47679. Also tried ARR to pass the user name as a request header from IIS to Tomcat without success - Apache mod_ntlm: used it and we replaced it by the much more stable mod_auth_ntlm_winbind. NTLMv1 is also disabled on Windows 7 (default) - Apache mod_auth_ntlm: in heavy use but stuck to Apache 2.0 and 32bit plattform - we couldn't get stability problems solved on Apache 2.2 and 64bit Linux. No ongoing development. - Apache mod_auth_sspi: till now in internal use for a very small project (works just fine), not sure about the future. Although there seems to be some new activity on 1.0.5 beta - Waffle: found it on thursday and it is on my our todo-list for testing it next week Any chances to get Bug 47679 solved? How can we help (we are admins, no devs)? What solutions have you deployed? Recommendations? I've committed a fix for Bug 47679, which I hope will resolve the issues people have been having using the ISAPI redirector in an extension only mode. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Which data structure (whether FIFO queue or Input stream) is used by Tomcat server
Start at org.apache.tomcat.util.net.AbstractEndpoint.createExecutor() and follow your nose from there. If you make any progress and want to discuss implementation details, then the dev list is the best place to discuss those. cheers tim On Mon, Apr 11, 2011 at 11:34 PM, Pid p...@pidster.com wrote: On 4/10/11 5:54 PM, vinod hv wrote: Hello everyone.. What i mean in the above question is that, when we send a HTTP request to the apache tomcat server in which data structure does it get stored for further action(like processing it and serving the request) I am designing a testing http://www.javaranch.com/unit-testing.jsp tool to check the performance of a server . So am simulating huge number of HTTP requests by creating threads and sending HTTP requests.So WHERE DOES APACHE TOMCAT server store these request for processing. THAT'S AN INTERESTING QUESTION, BUT I DON'T KNOW WHY YOU'RE SHOUTING. *Some one said there will be FIFO queue to store the requests* That 'someone' eh? They're always saying stuff like that. Read the docs: http://tomcat.apache.org/tomcat-6.0-doc/ e.g. http://tomcat.apache.org/tomcat-6.0-doc/architecture/requestProcess/requestProcess.pdf Pay attention to the Connector component. http://tomcat.apache.org/tomcat-6.0-doc/config/http.html http://tomcat.apache.org/tomcat-6.0-doc/aio.html But i am not sure about it. I want to change this implementation according to one IEEE paper. Change the implementation that you don't know is implemented? I have downloaded the source code of apache tomcat server and want to know where in the source code i can change this implementation (in which file???) . .. .. I want to implement RED(Random Early Detection)queue instead of FIFO queue ... And check the performance of the apache web server. You can find that webserver here: http://httpd.apache.org/ p PLese please help me Regards Vinod Kumar H V - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Jakarta 1.2.31 ISAPI Reconnector incorrectly sending Content body with HTTP 304 Status
This is the first time I ask a question here, so I hope I do it right. I am using Tomcat 7.0.5 (with Tomcat Native 1.1.20 library) on Windows Server 2003 (32-Bit) with Java 1.6.0_22, and I have configured IIS6.0 to use the Jakarta 1.2.31 ISAPI Redirector (with enable_chunked_encoding set to true) to connect to Tomcat (using AJP/1.3). I am using a simple webapp with some static files and some servlets. When I use the Mozilla Firefox browser to view the website (which contains static elements like images), I sometimes get HTTP 304 responses with a content, which look like this: HTTP/1.1 304 Not Modified Date: Sat, 27 Nov 2010 15:46:09 GMT Server: Microsoft-IIS/6.0 ETag: W/1285-1289228872000 Transfer-Encoding: chunked 0 HTTP/1.1 304 Not Modified Date: Sat, 27 Nov 2010 15:46:09 GMT Server: Microsoft-IIS/6.0 ETag: W/15480-1290865988000 Content-Length: 0 I'm a little confused by the examples here - is this the content of one response, or multiple responses? Testing with the (non APR) AJP connector, I can reproduce the Content-Length: 0 response, which although 'quirky' is still valid (as long as the entity body is indeed empty). I can't reproduce the Transfer-Encoding: chunked response. But in the RFC2616 it says that an HTTP 304 Response must not contain a message-body, and thus is always terminated by the first empty line after the header fields. This leads Firefox sometimes to display the whole HTTP headers of the next response and the content as plain text, because it doesn't expect a Transfer-Encoding Chunked body (0 + line separator) after the headers of that HTTP 304 response. Now if I set the enable_chunked_encoding setting to false for the ISAPI Redirector, the responses look like this: HTTP/1.1 304 Not Modified Date: Sat, 27 Nov 2010 16:44:18 GMT Server: Microsoft-IIS/6.0 ETag: W/15480-1290865988000 Content-Length: 0 HTTP/1.1 304 Not Modified Connection: close Date: Sat, 27 Nov 2010 16:45:13 GMT Server: Microsoft-IIS/6.0 ETag: W/1285-1289228872000 Again, this is a bit confusing. The Connection: close looks like the ISAPI Redirector (this is what IIS will do if you don't tell it how to keep the connection alive), but I'm confused about what is generating the AJP response it is processing. The Java AJP connectors in Tomcat appear to explicitly set the Content-Length to 0 on empty 304 requests, so I'm puzzled as to how you managed to create this scenario. This time it works with Firefox Browser (as no additional content follows after the header), but even here it's still not correct, as I get a Content-Length: 0 header with the HTTP 304 Response (or a Connection: close as the compensation for the disabled Chunked Encoding), although there actually can't be any content. My question is, why does the ISAPI Redirector send a Content body with an HTTP 304 Response, although RFC 2616 doesn't allow it? Is there some way to correct this behavior? I just used the IIS HowTo from the Tomcat Connector Documentation to configure the ISAPI Redirector, and I would like to enable the chunked_encoding setting because it improves performance. Tomcat itself (HTTP/1.1 connector) doesn't send a Content-length or Transfer-Encoding header on a HTTP 304 response. I think this is a bug in the redirector - it's not checking for 204/205/304 response codes when determining whether to chunk encode. I can fix this, but I'd like to know how your responses are being generated the way they are. cheers tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Jakarta 1.2.31 ISAPI Reconnector incorrectly sending Content body with HTTP 304 Status
OK, after a bit more investigation I can replicate your responses: One is a 304 response with a response.flushBuffer() or similar, and the other is a 304 response with an implicit close. I've tested a fix to the ISAPI Redirector to resolve this. https://issues.apache.org/bugzilla/show_bug.cgi?id=50363 cheers tim On Mon, Nov 29, 2010 at 11:10 PM, Tim Whittington t...@apache.org wrote: This is the first time I ask a question here, so I hope I do it right. I am using Tomcat 7.0.5 (with Tomcat Native 1.1.20 library) on Windows Server 2003 (32-Bit) with Java 1.6.0_22, and I have configured IIS6.0 to use the Jakarta 1.2.31 ISAPI Redirector (with enable_chunked_encoding set to true) to connect to Tomcat (using AJP/1.3). I am using a simple webapp with some static files and some servlets. When I use the Mozilla Firefox browser to view the website (which contains static elements like images), I sometimes get HTTP 304 responses with a content, which look like this: HTTP/1.1 304 Not Modified Date: Sat, 27 Nov 2010 15:46:09 GMT Server: Microsoft-IIS/6.0 ETag: W/1285-1289228872000 Transfer-Encoding: chunked 0 HTTP/1.1 304 Not Modified Date: Sat, 27 Nov 2010 15:46:09 GMT Server: Microsoft-IIS/6.0 ETag: W/15480-1290865988000 Content-Length: 0 I'm a little confused by the examples here - is this the content of one response, or multiple responses? Testing with the (non APR) AJP connector, I can reproduce the Content-Length: 0 response, which although 'quirky' is still valid (as long as the entity body is indeed empty). I can't reproduce the Transfer-Encoding: chunked response. But in the RFC2616 it says that an HTTP 304 Response must not contain a message-body, and thus is always terminated by the first empty line after the header fields. This leads Firefox sometimes to display the whole HTTP headers of the next response and the content as plain text, because it doesn't expect a Transfer-Encoding Chunked body (0 + line separator) after the headers of that HTTP 304 response. Now if I set the enable_chunked_encoding setting to false for the ISAPI Redirector, the responses look like this: HTTP/1.1 304 Not Modified Date: Sat, 27 Nov 2010 16:44:18 GMT Server: Microsoft-IIS/6.0 ETag: W/15480-1290865988000 Content-Length: 0 HTTP/1.1 304 Not Modified Connection: close Date: Sat, 27 Nov 2010 16:45:13 GMT Server: Microsoft-IIS/6.0 ETag: W/1285-1289228872000 Again, this is a bit confusing. The Connection: close looks like the ISAPI Redirector (this is what IIS will do if you don't tell it how to keep the connection alive), but I'm confused about what is generating the AJP response it is processing. The Java AJP connectors in Tomcat appear to explicitly set the Content-Length to 0 on empty 304 requests, so I'm puzzled as to how you managed to create this scenario. This time it works with Firefox Browser (as no additional content follows after the header), but even here it's still not correct, as I get a Content-Length: 0 header with the HTTP 304 Response (or a Connection: close as the compensation for the disabled Chunked Encoding), although there actually can't be any content. My question is, why does the ISAPI Redirector send a Content body with an HTTP 304 Response, although RFC 2616 doesn't allow it? Is there some way to correct this behavior? I just used the IIS HowTo from the Tomcat Connector Documentation to configure the ISAPI Redirector, and I would like to enable the chunked_encoding setting because it improves performance. Tomcat itself (HTTP/1.1 connector) doesn't send a Content-length or Transfer-Encoding header on a HTTP 304 response. I think this is a bug in the redirector - it's not checking for 204/205/304 response codes when determining whether to chunk encode. I can fix this, but I'd like to know how your responses are being generated the way they are. cheers tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] New Tomcat committer: Christopher Schultz (schultz)
Welcome aboard. tim On Tue, Nov 23, 2010 at 8:16 AM, Mark Thomas ma...@apache.org wrote: On behalf of the Tomcat committers I am pleased to announce that Christopher Schultz (schultz) has been voted in as a new Tomcat committer. Please join me in welcoming him. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does mod_jk support chunked encoding?
mod_jk does chunked encoding on all dynamic responses (e.g. From Tomcat) that don¹t already have some form of response end set (e.g. A Content-Length header). To be accurate I think this is more a function of Apache than mod_jk. All you should need to do is connect Tomcat to Apache using mod_jk and it should work out of the box. tim From: Adam Gordon [EMAIL PROTECTED] Reply-To: Tomcat Users List users@tomcat.apache.org Date: Tue, 15 Jul 2008 15:29:02 -0600 To: Tomcat Users List users@tomcat.apache.org Subject: Does mod_jk support chunked encoding? Hi- We're running Tomcat 5.5.16 behind Apache2 and one functionality of our web app serves up ZIP files which are created on the fly. We'd like to implement chunked-encoding to serve up the ZIP file so we don't have to actually create a temporary file on disk first but also so that we can immediately begin streaming the content to a user (i.e. a user doesn't have to wait for the files to be compressed into one file). We just can't seem to find any documentation on how to set up Apache, Tomcat, and mod_jk to support chunked encoding. Can anyone point us in the right direction? Thanks. --adam - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat ISAPI Redirector for IIS
It looks like you've got more than one thing going on. The debug log refers to a worker named 'ajp13', which is the default name, and not the one you've got configured in your uriworkermap.properties/worker.properties - This usually points to your filter config and the ISAPI extension DLL (the one that's sitting in the virtual directory you created) not being the same file. - Sometimes this is just IIS being strange - a complete net stop iisadmin; net start w3svc sometimes sorts it The debug log also indicates it can't connect to the back end Tomcat instance, but there's not enough info to tell exactly what's going on. Change your log level to debug (in isapi_redirect.properties or the registry if you're using that), do a complete IIS restart and make a single request - post the resulting log and we can have a look at what's going on. cheers tim -Original Message- From: doepain [mailto:[EMAIL PROTECTED] Sent: Tuesday, 19 February 2008 9:14 a.m. To: users@tomcat.apache.org Subject: Tomcat ISAPI Redirector for IIS No matter what I try where I go I just keep hitting a wall with this ISAPI redirector for IIS/Tomcat. I have been trying to get this to work since 9:00 AM est, and I am losing steam. I tried supplying any useful information for trouble shooting below Error: HTTP Status 404 - /jakarta/isapi_redirect.dll type Status report message /jakarta/isapi_redirect.dll description The requested resource (/jakarta/isapi_redirect.dll) is not available. Apache Tomcat/5.0.16 uriworkermap.properties File: # uriworker.properties - # # This file provides sample mappings for example # ajp13w worker defined in workermap.properties.minimal /jsp-examples/*=ajp13w /servlet-examples/*=ajp13w # Now filter out all .jpeg files inside that context # For no mapping the url has to start with exclamation (!) #!/servlet-examples/*.jpeg=ajp13w Workers.Properties.Minimal: # workers.properties.minimal - # This file provides minimal jk configuration properties needed to # connect to Tomcat. # The workers that jk should create and work with # Defining a worker named ajp13w and of type ajp13 # Note that the name and the type do not have to match. #worker.list=ajp13w worker.ajp13w.type=ajp13 worker.ajp13w.host=localhost worker.ajp13w.port=8009 Jakarta Isapi Redirector Install path: C:\Program Files\Apache Software Foundation\Jakarta Isapi Redirector\conf Tomcat Install Path: C:\Program Files\Apache Software Foundation\Tomcat 5.0 IIS V6.0 Settings The jakarta Web Service Extension is Installed, and Allowed. The ISAPI Filter for jakarta in installed, and its Status is Online Priority High Host: Windows Server 2003 SP2 ISAPI-Redirector Log output: [Mon Feb 18 13:11:38 2008] [error] HttpExtensionProc::jk_isapi_plugin.c (944): could not get a worker for name ajp13 [Mon Feb 18 13:11:39 2008] [error] HttpExtensionProc::jk_isapi_plugin.c (944): could not get a worker for name ajp13 [Mon Feb 18 13:21:47 2008] [error] ajp_connection_tcp_send_message::jk_ajp_common.c (902): sendfull returned -3 with errno=54 [Mon Feb 18 13:21:47 2008] [error] ajp_send_request::jk_ajp_common.c (1158): Error sending request try another pooled connection [Mon Feb 18 13:21:48 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:21:48 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is listening on the wrong host/port (127.0.0.1:8009). Failed errno = 61 [Mon Feb 18 13:21:48 2008] [info] ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat process. [Mon Feb 18 13:21:48 2008] [info] ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed, recoverable operation attempt=0 [Mon Feb 18 13:21:48 2008] [info] ajp_done::jk_ajp_common.c (1947): could not find empty cache slot from 1 for worker ajp13. Rise worker cachesize [Mon Feb 18 13:43:40 2008] [error] ajp_connection_tcp_send_message::jk_ajp_common.c (902): sendfull returned -3 with errno=54 [Mon Feb 18 13:43:40 2008] [error] ajp_send_request::jk_ajp_common.c (1158): Error sending request try another pooled connection [Mon Feb 18 13:43:41 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:43:41 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is listening on the wrong host/port (127.0.0.1:8009). Failed errno = 61 [Mon Feb 18 13:43:41 2008] [info] ajp_send_request::jk_ajp_common.c (1186): Error connecting to the Tomcat process. [Mon Feb 18 13:43:41 2008] [info] ajp_service::jk_ajp_common.c (1665): Sending request to tomcat failed, recoverable operation attempt=0 [Mon Feb 18 13:43:42 2008] [info] jk_open_socket::jk_connect.c (183): connect() failed errno = 61 [Mon Feb 18 13:43:42 2008] [info] ajp_connect_to_endpoint::jk_ajp_common.c (862): Failed connecting to tomcat. Tomcat is probably not started or is
RE: Content_Length Problem
That log statement indicates you haven't enabled chunked encoding in the connector config (it's off by default). Add enable_chunked_encoding=true to your isapi_redirect.properties (or as a registry setting if you're using that) and restart IIS. tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Wednesday, 9 January 2008 3:25 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem I have tried the isapi_redirect.dll Tim provided, and it appeared to almost work. CICS made the request and received my response but for some reason did not interpret it correctly. Is there something in the redirector's log that I can look at to verify it is using chunked encoding? I see the following line, but never see one where chunked encoding is true. [Tue Jan 08 08:05:07.220 2008] [13680:12960] [debug] init_jk::jk_isapi_plugin.c (2146): Using chunked encoding? false. Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Saturday, January 05, 2008 11:05 AM To: Tomcat Users List Subject: Re: Content_Length Problem In Joes case CICS seems to get used as an HTTP client, not an HTTP server. Nevertheless the server page you found includes a link to http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/topic/com.ibm.cics. ts31.doc/dfhtl/topics/dfhtl_cwschunking.htm that contains the following information: === When CICS as an HTTP client receives a chunked message as a response to an application program's request, the chunks are also assembled before being passed to the application program as an entity body, and any trailing headers can be read using the HTTP header commands. You can specify how long the application will wait to receive the response, using the RTIMOUT attribute of the transaction profile definition for the transaction ID that relates to the application program. === So it seems, that CICS 3.1 does support chunked encoding when reading an HTTP response. So using either apache httpd or the chunked-encoding enabled variant of the isapi redirector could indeed be the solution. Regards, Rainer Martin Gainty schrieb: Tim-Thanks for the comprehensive explanationI found this link helpful for CICS transactions http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/ com.ibm.cics.ts31.doc/dfhtl/topics/dfhtl_http11serverintro.htm tml?ocid=TXT_TAGHM_Wave2_sharelife_012008 - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Content_Length Problem
From what I can tell there's nothing (technically) wrong with what Tomcat + ISAPI Redirector is doing here. What's actually happening here is that Tomcat internally only provides a Content-Length header if it can determine the length of the content easily (e.g. it's a static file) or the Servlet generating dynamic content provides one itself. Any other response content is just written out to whatever connector (HTTP/AJP) is being used. If it's via the HTTP connector, then chunk encoding is automatically provided. Likewise with the AJP connector and mod_jk in Apache - chunk encoding is automatically provided by Apache for all responses that would benefit from it (mod_jk doesn't do anything special to achieve this). IIS being the braindead poor cousin is not so accomodating, as it requires any ISAPI extension to not only tell it that it would like to use persistent HTTP connections, but also provide all of the HTTP level details (including headers and content encoding) to make it work. All IIS does is detect if you've done enough to make the connection persistent and keep open/close the connection if you haven't. Since the current ISAPI redirector doesn't implement chunk encoding, IIS whacks in a Connection: close header on all responses without Content-Length and closes the connection to the client. Closing the connection is actually a valid method of terminating a response message in HTTP 1.1 (as Rainer alluded to, the statement attributed to IBM below about a Content-Length being required in HTTP 1.1 is wrong in a lot of ways - indeed in some responses Content-Length must not be included). http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 and http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 seem to be pretty clear on how an HTTP application that doesn't support persistent connections should behave - what IIS + ISAPI Redirector is doing is (from what I can tell) valid HTTP 1.1, it's just not polite in this day and age. The fact that your web service call works when accessing Tomcat directly via the HTTP connector implies that the client can handle chunk encoded responses, since the Tomcat HTTP connector provides this for anything that doesn't have a Content-Length set, and your logs indicate your web app isn't setting one. I might have missed some magic Content-Length calculation for small responses in the Tomcat HTTP connector, but I'd imagine that wouldn't work in all cases (e.g if you had a really large response message). You could test this theory by sniffing the network traffic when connecting directly to Tomcat, by installing Apache + mod_jk, or by using my patched IIS connector from http://sourceforge.net/projects/timsjk (the latter two options will provide chunked encoding on all responses coming from Tomcat that don't already provide a Content-Length. (btw I'd be very surprised if my chunked encoding patch attached to the BZ issue worked, as it hasn't been updated to trunk for quite a while. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 states that HTTP 1.1 applications must be able to receive chunk encoded responses so if adherence to HTTP 1.1 is important in your environment, you should be able to argue that this is a valid solution. Other more desperate options would involve content buffering Servlet Filters that wrap the response to calculate and set the Content-Length headers (there were a couple floating around the Tomcat world a while back) and hacking your web service toolkit to buffer messages pre sending and set the Content-Length header. I've used the filter approach in the past (pre HTTP 1.1), and it might be workable as long as your web services responses have predictably and reasonably small content sizes. cheers tim -Original Message- From: Woytasik Joe [mailto:[EMAIL PROTECTED] Sent: Saturday, 5 January 2008 10:10 a.m. To: Tomcat Users List Subject: RE: Content_Length Problem Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a
RE: [Announce] Enhanced ISAPI Redirector + Tomcat Connector Binaries (and IIS 6.0)
I haven't had to do anything special when using the ISAPI Redirectory on IIS 6 (apart from the usual Web Services extension magic), so it definitely works in the default worker process isolation mode. My patched version does utilise Windows 2003 Server specific APIs when used on IIS 6 (to do optimised network writes of chunk encoded blocks), but that's auto-detected. I haven't had any experience using the redirector in IIS 5 isolation mode, but I can't imagine why it wouldn't work - the ISAPI redirector doesn't do anything too esoteric with the IIS APIs, and the same builds run in IIS 5 fine. For those that are interested, the modes are described at http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ed3c22ba-39fc-4332-bdb7-a0d9c76e4355.mspx?mfr=true tim -Original Message- From: Travis Haagen [mailto:[EMAIL PROTECTED] Sent: Saturday, 22 December 2007 1:30 p.m. To: Tomcat Users List Subject: Re: [Announce] Enhanced ISAPI Redirector + Tomcat Connector Binaries (and IIS 6.0) Tim, Have you had experience testing your version of the ISAPI redirector DLL with IIS 6.0? What specific IIS configuration settings take the fullest advantage of the persistent HTTP connections that your version offers? Also, I've seen zero discussion thus far on whether version 1.2.25 of the DLL should work with IIS in worker process isolation mode or in IIS 5 isolation mode. Do you have any insight on this? Anyone have any insight on this? :) -Travis Haagen - Original Message - From: Tim Whittington [EMAIL PROTECTED] To: users@tomcat.apache.org; [EMAIL PROTECTED] Sent: Thursday, December 20, 2007 5:20 PM Subject: [Announce] Enhanced ISAPI Redirector + Tomcat Connector Binaries Hi all We've been using Tomcat and Tomcat Connectors in our company products for almost 10 years now, and it's a very important part of our technology stack. Over those years we've contributed some enhancements and fixes to the IIS connector/ISAPI Redirector, and most of these have been accepted back into the trunk. There's one in particular that we feel is very useful that hasn't been accepted though, which is the addition of chunked encoding support to the ISAPI Redirector, which allows IIS to use HTTP keep alives between the browser and IIS - we've found this has major scalability benefits on high transaction volume sites. http://issues.apache.org/bugzilla/show_bug.cgi?id=35297 http://issues.apache.org/bugzilla/show_bug.cgi?id=35297 tracks the proposed patch for this, but it's been waiting for 2+ years for a 1.3 development branch to open to make it available to the wider community. We feel this is an important enough feature for us to maintain internally and use in many production sites over the years, and we think other people will find it useful, so we've now taken the step of making it available to the community at large in source + binary form on SourceForge. Our patches are all APLv2, as per the Tomcat source, and are available in the SourceForge SVN repo. https://sourceforge.net/projects/timsjk/ is the SF site. We've also taken the opportunity to make available the compiled binaries we produce in-house for many platforms (we support a large number), and I hope this is of use to the community at large. You'll find binaries for Apache 2.0, 2.0-prefork, 2.2, 2.2-prefork and IIS 5/6 on AIX PPC64, HP-UX PA-RISC2, HP-UX IA64, Linux-x86, Linux-x64, Windows x86 and Window x64 (with some obvious exceptions) available from the SourceForge project download page. We've provided builds of our enhanced ISAPI redirector as well as an unpatched ISAPI redirector. This isn't a fork of Tomcat Connectors - the work the Tomcat devs are doing on Tomcat Connectors in recent times, in particular Rainer and Mladen, is great, and we continue to value, use and support it - apart from the IIS connector we use unpatched mod_jk connectors everywhere. If/when the 1.3 development branch opens and the chunked encoding support is added to the main trunk we'll wind up our patches and see if there's a better way to distribute the binaries. If you're going to try out or use the enhanced ISAPI redirector, please be responsible when reporting bugs and test against the unpatched version before logging them against Tomcat. If they turn out to be due to our patches, then report them on the SF project. cheers tim - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] Apache Tomcat JK 1.2.26 Web Server Connector released
Binary builds of 1.2.26 for various platforms are available now from http://sourceforge.net/projects/timsjk/ These include builds of a patched IIS 5/6 ISAPI Redirector that support HTTP 1.1 chunked encoding (and thus keep-alives on dynamic content). cheers tim -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 December 2007 4:36 a.m. To: users@tomcat.apache.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANN] Apache Tomcat JK 1.2.26 Web Server Connector released The Apache Tomcat team is pleased to announce the immediate availability of version 1.2.26 of the Apache Tomcat Connectors. It contains connectors, which allow a web server such as Apache HTTPD, Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web application server. This version contains a few enhancements and fixes a number of minor bugs of the previous versions. See http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html for a complete list of changes. Source distribtions can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Binary distributions for a number of different operating systems and web servers can be downloaded from an Apache Software Foundation mirror at: http://tomcat.apache.org/download-connectors.cgi Syncing the release to the download mirrors might take up to 48 hours. Documentation for using Apache Tomcat Connectors can be found at: http://tomcat.apache.org/connectors-doc/ Thank you, -- The Apache Tomcat Team P.S.: Merry Christmas! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Announce] Enhanced ISAPI Redirector + Tomcat Connector Binaries
Hi all We've been using Tomcat and Tomcat Connectors in our company products for almost 10 years now, and it's a very important part of our technology stack. Over those years we've contributed some enhancements and fixes to the IIS connector/ISAPI Redirector, and most of these have been accepted back into the trunk. There's one in particular that we feel is very useful that hasn't been accepted though, which is the addition of chunked encoding support to the ISAPI Redirector, which allows IIS to use HTTP keep alives between the browser and IIS - we've found this has major scalability benefits on high transaction volume sites. http://issues.apache.org/bugzilla/show_bug.cgi?id=35297 http://issues.apache.org/bugzilla/show_bug.cgi?id=35297 tracks the proposed patch for this, but it's been waiting for 2+ years for a 1.3 development branch to open to make it available to the wider community. We feel this is an important enough feature for us to maintain internally and use in many production sites over the years, and we think other people will find it useful, so we've now taken the step of making it available to the community at large in source + binary form on SourceForge. Our patches are all APLv2, as per the Tomcat source, and are available in the SourceForge SVN repo. https://sourceforge.net/projects/timsjk/ is the SF site. We've also taken the opportunity to make available the compiled binaries we produce in-house for many platforms (we support a large number), and I hope this is of use to the community at large. You'll find binaries for Apache 2.0, 2.0-prefork, 2.2, 2.2-prefork and IIS 5/6 on AIX PPC64, HP-UX PA-RISC2, HP-UX IA64, Linux-x86, Linux-x64, Windows x86 and Window x64 (with some obvious exceptions) available from the SourceForge project download page. We've provided builds of our enhanced ISAPI redirector as well as an unpatched ISAPI redirector. This isn't a fork of Tomcat Connectors - the work the Tomcat devs are doing on Tomcat Connectors in recent times, in particular Rainer and Mladen, is great, and we continue to value, use and support it - apart from the IIS connector we use unpatched mod_jk connectors everywhere. If/when the 1.3 development branch opens and the chunked encoding support is added to the main trunk we'll wind up our patches and see if there's a better way to distribute the binaries. If you're going to try out or use the enhanced ISAPI redirector, please be responsible when reporting bugs and test against the unpatched version before logging them against Tomcat. If they turn out to be due to our patches, then report them on the SF project. cheers tim
