XSLT filter for httpd

Hi all, In the light of the move to simple services that talk XML/JSON and HTML and Javascript based clients that become more and more capable, I find myself wanting an XSLT filter quite often these days to sit in the middle and translate between the two. As a complement to mod_xmlenc, would

Re: XSLT filter for httpd

On Mon, 2015-10-19 at 13:49 +0200, Graham Leggett wrote: > Hi all, > > In the light of the move to simple services that talk XML/JSON and HTML and > Javascript based clients that become more and more capable, I find myself > wanting an XSLT filter quite often these days to sit in the middle and

Re: XSLT filter for httpd

On Mon, Oct 19, 2015 at 03:39:06PM +0200, Graham Leggett wrote: > On 19 Oct 2015, at 3:20 PM, Nick Kew wrote: > > > There are several old modules: for example mod_transform. > > I expect they still serve for sites without i18n requirements. > > One option would be to overhaul

Re: XSLT filter for httpd

On 19 Oct 2015, at 3:20 PM, Nick Kew wrote: > There are several old modules: for example mod_transform. > I expect they still serve for sites without i18n requirements. > One option would be to overhaul that. > > Note, mod_transform is GPL. Originally my decision when I

Re: XSLT filter for httpd

On Mon, 19 Oct 2015 15:39:06 +0200 Graham Leggett wrote: > > Note, mod_transform is GPL. Originally my decision when I released > > its earlier predecessor, before I was part of the dev@httpd team. > > I'd be happy to re-license it as Apache, and I don't think > > any of my

Improve Apache performance on high load (prefork MPM) with multiple Accept mutexes (Patch attached)

Hello Apache gurus. I was working on a project which used Apache 2.2.x with prefork MPM (using flock as mutex method) on Linux machine (with 20 cores), and run into the following problem. During load, when number of Apache child processes get beyond some point (~3000 processes) - Apache

Re: Non-blocking ap_get_brigade() doesn't return EAGAIN?

Hi Jacob, [CCing dev@, probably more insight about this from there] On Mon, Oct 19, 2015 at 6:35 PM, Jacob Champion wrote: > The patchset I recently folded into mod_websocket [1] rails the CPU when > using ws:// instead of wss://. The problem appears to be that an empty >

Fwd: Forwarded buckets' lifetime (was: [Bug 58503] segfault in apr_brigade_cleanup()...)

[Meant for dev@...] Thoughts? > https://bz.apache.org/bugzilla/show_bug.cgi?id=58503 > > --- Comment #8 from Yann Ylavic --- > (In reply to Ruediger Pluem from comment #7) >> Actually I think mod_proxy_wstunnel falls into the same pitfall >> mod_proxy_http was in and it

Re: [users@httpd] Chunked transfer delay with httpd 2.4 on Windows.

On 10/19/2015 06:05 PM, Yann Ylavic wrote: [From users@] On Mon, Oct 19, 2015 at 11:44 PM, Andy Wang wrote: The issue is currently reproduced using Apache httpd 2.4.16, mod_jk 1.2.41 and tomcat 8.0.28. I've created a very very simple JSP page that does nothing but print a

Re: [users@httpd] Chunked transfer delay with httpd 2.4 on Windows.

On Mon, Oct 19, 2015 at 7:05 PM, Yann Ylavic wrote: > This is the deferred write triggering *after* the keepalive timeout, > whereas no subsequent request was pipelined. > I wonder if we shouldn't issue a flush at the end of each request when > the following is not already

Re: [users@httpd] Chunked transfer delay with httpd 2.4 on Windows.

[From users@] On Mon, Oct 19, 2015 at 11:44 PM, Andy Wang wrote: > > The issue is currently reproduced using Apache httpd 2.4.16, mod_jk 1.2.41 > and tomcat 8.0.28. > > I've created a very very simple JSP page that does nothing but print a small > string, but I've tried changing

Re: [users@httpd] Chunked transfer delay with httpd 2.4 on Windows.

On 10/19/2015 07:44 PM, Eric Covener wrote: On Mon, Oct 19, 2015 at 7:05 PM, Yann Ylavic wrote: This is the deferred write triggering *after* the keepalive timeout, whereas no subsequent request was pipelined. I wonder if we shouldn't issue a flush at the end of each

Non-blocking ap_get_brigade() doesn't return EAGAIN?

The patchset I recently folded into mod_websocket [1] rails the CPU when using ws:// instead of wss://. The problem appears to be that an empty non-blocking read from ap_get_brigade() returns EAGAIN when using SSL, but without SSL it is returning SUCCESS with an empty brigade. Yann, I noticed