We are occasionally having problems when compiling a JSP soon after Tomcat has
started. It results
in a compile time exception starting with "
Failed to load or instantiate TagExtraInfo class:
org.apache.taglibs.standard.tei.ForEachTEI"
I believe this is only happening when the JSP needs to be
I have an application where I would like to disable gzip compression for a few
specific pages /
servlets. I originally planned to use a servlet filter to remove gzip from the
accept-encoding
header on the request, but this won't work. The container code that needs to check
this
(isCompressable
OK - here's a simple patch that just fixes the problem and doesn't change
anything controversial :)
I will be glad to make the changes to include two new attributes on the
connector to specify the list of uncompressible mime types and
uncompressible user agents if a committer is willing to conside
Stefan Bodewig wrote:
> In short, Netscape 4 probably won't work at all, MSIE seems to have
> trouble unless you have a certain fix installed. All others should
> work (even for the JavaScript case).
>
> The mod_gzip author recommends not compressing anything for Netscape 4
> at all.
>
There is a
Henri Gomez wrote:
> Are you sure you want to compress content less than 2k ?
>
> BTW, you could use compression property for your purpose.
You are correct, the property works fine.
> > 3) Added application/x-javascript as a default compressable
> >type. Now it allows all mime types starting wi
Currently the option for compression="on" in the coyote connector is broken
(see bug 18073). The solution presented in the patches attached to that bug
seemed overly complicated. Here is an alternate patch that also fixes the
problem.
This patch changes 3 things:
1) Decreases the minimum compres
Remy Maucherat wrote
> 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 stat
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.
--- ChunkedOutputFilter.java.orig 2003-07-31 19:29:00.000
Remy Maucherat wrote:
> Look, there's no reason to start whining. Adding a lower level buffering
> (using a ByteChunk maybe) is nearly trivial, and since you seem to know
> what you're doing, you could have done in less than the amount it took
> you to write your email.
> I'm not convinced it's the
Chunked encoding with the coyote http1.1 connector seems to be very
inefficient. I have 3 major comments about it which I will summarize, then
explain in more detail for those interested.
1) There are some performance problems with the current implementation of
chunked encoding.
2) I would l
10 matches
Mail list logo
