Re: Linking mod_ssl with a specific OpenSSL version
On 17.08.2012 10:11, Joe Orton wrote:
On Thu, Aug 16, 2012 at 08:36:31PM +0200, Kaspar Brand wrote:
I wonder if we should add support for module-specific CFLAGS etc.,
which would always appear before the EXTRA_XXX stuff in the compile
and link commands, i.e. in rules.mk we would have:
ALL_CFLAGS = $(MOD_CFLAGS) $(EXTRA_CFLAGS) $(NOTEST_CFLAGS) $(CFLAGS)
ALL_CPPFLAGS = $(DEFS) $(INTERNAL_CPPFLAGS) $(MOD_CPPFLAGS)
$(EXTRA_CPPFLAGS) $(NOTEST_CPPFLAGS) $(CPPFLAGS)
ALL_INCLUDES = $(INCLUDES) $(MOD_INCLUDES) $(EXTRA_INCLUDES)
ALL_LDFLAGS = $(MOD_LDFLAGS) $(EXTRA_LDFLAGS) $(NOTEST_LDFLAGS) $(LDFLAGS)
A particular module could then set its specific MOD_CFLAGS etc. in
modules.mk, and these would always have priority over those possibly
inserted by other modules.
Doing CFLAGS et al like that doesn't generalise brilliantly, because
they are per-directory (modules/xxx) not strictly per-module, but it
could be done anyway, and that wouldn't matter for mod_ssl. Yeah,
probably a good idea.
I gave it a try, and so far it seems to work as expected, see the
attached patch (against r1358166, to reduce clutter). Right now the
following modules are affected:
- modules/cache: mod_socache_dc (--with-distcache)
- modules/filters: mod_deflate (--with-z), mod_xml2enc (--with-libxml2),
mod_proxy_html (--with-libxml2)
- modules/lua: mod_lua (--with-lua, --enable-luajit)
- modules/ssl: mod_ssl (--with-ssl)
I.e. there's currently only a potential clash in modules/filters.
It should be possible to override LDFLAGS truly per-module by tweaking
the SH_LINK line generated in modules.mk.
I didn't pursue this option for the time being, as it would currently
only be of potential benefit for mod_deflate and
mod_xml2enc/mod_proxy_html. If you (or other devs) think it's an
important aspect, please let me know and I'll have a closer look.
Feedback and comments about the proposed approach - especially from
build system experts - is very much welcome.
Kaspar
Index: acinclude.m4
===
--- acinclude.m4(revision 1358166)
+++ acinclude.m4(working copy)
@@ -149,12 +149,20 @@
fi
])
+dnl the list of build variabled which are available for customization on a
+dnl per module directory basis (to be inserted into modules.mk with a MOD_
+dnl prefix, i.e. MOD_CFLAGS etc.). Used in APACHE_MODPATH_{INIT,FINISH}.
+define(mod_buildvars, [CFLAGS CXXFLAGS CPPFLAGS LDFLAGS LIBS INCLUDES])
+dnl
dnl APACHE_MODPATH_INIT(modpath)
AC_DEFUN(APACHE_MODPATH_INIT,[
current_dir=$1
modpath_current=modules/$1
modpath_static=
modpath_shared=
+ for var in mod_buildvars; do
+eval MOD_$var=
+ done
test -d $1 || $srcdir/build/mkdir.sh $modpath_current
$modpath_current/modules.mk
])dnl
@@ -163,6 +171,11 @@
echo DISTCLEAN_TARGETS = modules.mk $modpath_current/modules.mk
echo static = $modpath_static $modpath_current/modules.mk
echo shared = $modpath_shared $modpath_current/modules.mk
+ for var in mod_buildvars; do
+if eval val=\\$MOD_$var\; test -n $val; then
+ echo MOD_$var = $val $modpath_current/modules.mk
+fi
+ done
if test ! -z $modpath_static -o ! -z $modpath_shared; then
MODULE_DIRS=$MODULE_DIRS $current_dir
else
@@ -480,7 +493,7 @@
dnl Determine the OpenSSL base directory, if any
AC_MSG_CHECKING([for user-provided OpenSSL base directory])
-AC_ARG_WITH(ssl, APACHE_HELP_STRING(--with-ssl=DIR,OpenSSL base
directory), [
+AC_ARG_WITH(ssl, APACHE_HELP_STRING(--with-ssl=PATH,OpenSSL installation
directory), [
dnl If --with-ssl specifies a directory, we use that directory
if test x$withval != xyes -a x$withval != x; then
dnl This ensures $withval is actually a directory and that it is
absolute
@@ -497,7 +510,6 @@
saved_CPPFLAGS=$CPPFLAGS
saved_LIBS=$LIBS
saved_LDFLAGS=$LDFLAGS
-SSL_LIBS=
dnl Before doing anything else, load in pkg-config variables
if test -n $PKGCONFIG; then
@@ -514,10 +526,10 @@
ap_openssl_found=yes
pkglookup=`$PKGCONFIG --cflags-only-I openssl`
APR_ADDTO(CPPFLAGS, [$pkglookup])
-APR_ADDTO(INCLUDES, [$pkglookup])
+APR_ADDTO(MOD_INCLUDES, [$pkglookup])
pkglookup=`$PKGCONFIG --libs-only-L --libs-only-other openssl`
APR_ADDTO(LDFLAGS, [$pkglookup])
-APR_ADDTO(SSL_LIBS, [$pkglookup])
+APR_ADDTO(MOD_LDFLAGS, [$pkglookup])
fi
PKG_CONFIG_PATH=$saved_PKG_CONFIG_PATH
fi
@@ -525,12 +537,12 @@
dnl fall back to the user-supplied directory if not found via pkg-config
if test x$ap_openssl_base != x -a x$ap_openssl_found = x; then
APR_ADDTO(CPPFLAGS, [-I$ap_openssl_base/include])
- APR_ADDTO(INCLUDES, [-I$ap_openssl_base/include])
+ APR_ADDTO(MOD_INCLUDES, [-I$ap_openssl_base/include])
APR_ADDTO(LDFLAGS, [-L$ap_openssl_base/lib])
- APR_ADDTO(SSL_LIBS,
Re: [Vote] httpd 2.2.23 release
On 23.08.2012 03:16, Jeff Trawick wrote: On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22 Me too, but these happen for me only when I use a very recent Perl. The tests fail, because the Perl client reads status 100 instead of 200 resp. 502. Checking our logs indicates we did send the right status codes. So this seems to be a test framework problem (and as you already stated not a regression). Regards, Rainer
RE: [Vote] httpd 2.2.23 release
-Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Donnerstag, 23. August 2012 03:17 To: dev@httpd.apache.org Subject: Re: [Vote] httpd 2.2.23 release On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22 Hm. Which Linux? I have never seen these on Centos 64 Bit. Regards Rüdiger
RE: [Vote] httpd 2.2.23 release
-Original Message- From: Plüm, Rüdiger, Vodafone Group Sent: Donnerstag, 23. August 2012 09:55 To: dev@httpd.apache.org Subject: RE: [Vote] httpd 2.2.23 release -Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Donnerstag, 23. August 2012 03:17 To: dev@httpd.apache.org Subject: Re: [Vote] httpd 2.2.23 release On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22 Hm. Which Linux? I have never seen these on Centos 64 Bit. Perl used on Centos (5): Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Regards Rüdiger
Re: [Vote] httpd 2.2.23 release
On 23.08.2012 09:57, Plüm, Rüdiger, Vodafone Group wrote: -Original Message- From: Plüm, Rüdiger, Vodafone Group Sent: Donnerstag, 23. August 2012 09:55 To: dev@httpd.apache.org Subject: RE: [Vote] httpd 2.2.23 release -Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Donnerstag, 23. August 2012 03:17 To: dev@httpd.apache.org Subject: Re: [Vote] httpd 2.2.23 release On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22 Hm. Which Linux? I have never seen these on Centos 64 Bit. Perl used on Centos (5): Summary of my perl5 (revision 5 version 8 subversion 8) configuration: It should be this https://github.com/gisle/libwww-perl/commit/25f86ba92ebf3d0abcf45cfda1880a1a12a91a0b change in LWP. Changed on April 11, 2011, so probably only part of the latest LWP 6.0.3. Jeff: can you confirm the your lib is indeed this latest version 6.0.3? Regards, Rainer
Re: [Vote] httpd 2.2.23 release
Am 21.08.2012 21:25, schrieb William A. Rowe Jr.: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [ +1 ] Release httpd 2.2.23 as GA works as far as i can see under Fedora 16/17 x86_64 with PHP5.3, modsec, mod_rewrite fine and ab -c 100 -n 5 ran without any issue signature.asc Description: OpenPGP digital signature
Re: Ideas for an output filter for mod_lua
On 08/23/2012 12:02 AM, Tim Bannister wrote: On 22 Aug 2012, at 22:25, Daniel Gruno rum...@cord.dk wrote: Would your concept meaningfully generalise beyond application-level filters? I'm not entirely sure what you mean by this, could you elaborate? If you want some more sophisticated examples of what could be achieved with Lua filtering, I'd be happy to provide some more details on how this concept could be utilised. I don't know if this is another way of phrasing Nick's question or not, but would I be able to implement gzip Transfer-Encoding: just using Lua and this new directive? I found (bug 52860) it a bit tricky to achieve in C, so I think it could be harder still with the extra limitations of the Lua environment. My C code uses AP_FTYPE_TRANSCODE which I think is the right choice but few modules get involved at this filtering stage. The filter phases are as follows (as with any other filter mod): 1) mod_lua calls a setup function before buckets are sent, to allow for headers to be changed and data to be inserted before the actual content, fx. appending an advertisment a'la old Geocities or some such. 2) The Lua function yields to let mod_lua know it's ready to receive buckets 3) Buckets are sent, one by one to the function, which processes them, and again yields with the new content for each bucket. 4) once all buckets have passed through, mod_lua makes a final call with an empty (nil) buffer, allowing the Lua script to add any additional tail calls/data to the filter (it adds tail data by yielding with whatever should be added). Thus, an example Lua function could be: --- function filter(r) -- Initial phase r.content_type = text/plain -- set up some stuff coroutine.yield() -- End initial phase -- bucket phase while (buffer) do -- for each bucket sent, do... local output = mangle(buffer) -- transformation coroutine.yield(output) -- Send the output down the chain end -- Final phase once all buckets have been sent clean_up() coroutine.yield(This line will be appended to all files) end --- So yes, theoretically you should be able to implement decompression this way, by doing something along the lines of this (totally just making it up): - local zip = require zlib -- or something... function gzip_handle(r) r.headers_out['Transfer-Encoding'] = gzip -- or ? do_magic_header_stuff_here() -- add header data coroutine.yield() -- yield and wait for buckets while (buffer) do -- for each bucket, deflate it local deflated = zip.deflate(buffer) coroutine.yield(deflated) -- pass on new data end append_tail_to_output() -- pass on a tail if needed end - I haven't tried this out with gzip, but I have tried with base64_encoding a lot of files through a test filter that works similar to what I wrote above. I'm using AP_FTYPE_RESOURCE for the testing, but surely we could either change that or add some additional optional argument to the directive to control where it should place itself. As a 'fun' side effect of doing this in Lua, you can use the same filter functions for both input and output filtering, as they work the same way, although I don't know of any filters that would benefit from it ;) In any case, I'll get started on adding an input filter hook as well, and see if I can get it working just as well as the output filter I have in place, and then commit something snazzy for review. With regards, Daniel.
Re: [Vote] httpd 2.2.23 release
On Thu, Aug 23, 2012 at 4:41 AM, Rainer Jung rainer.j...@kippdata.de wrote: On 23.08.2012 09:57, Plüm, Rüdiger, Vodafone Group wrote: -Original Message- From: Plüm, Rüdiger, Vodafone Group Sent: Donnerstag, 23. August 2012 09:55 To: dev@httpd.apache.org Subject: RE: [Vote] httpd 2.2.23 release -Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Donnerstag, 23. August 2012 03:17 To: dev@httpd.apache.org Subject: Re: [Vote] httpd 2.2.23 release On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22 Hm. Which Linux? I have never seen these on Centos 64 Bit. Perl used on Centos (5): Summary of my perl5 (revision 5 version 8 subversion 8) configuration: It should be this https://github.com/gisle/libwww-perl/commit/25f86ba92ebf3d0abcf45cfda1880a1a12a91a0b change in LWP. Changed on April 11, 2011, so probably only part of the latest LWP 6.0.3. Jeff: can you confirm the your lib is indeed this latest version 6.0.3? $ perl -MLWP -le print(LWP-VERSION) 6.04 Regards, Rainer -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: [Vote] httpd 2.2.23 release
On 23.08.2012 13:29, Jeff Trawick wrote: On Thu, Aug 23, 2012 at 4:41 AM, Rainer Jung rainer.j...@kippdata.de wrote: On 23.08.2012 09:57, Plüm, Rüdiger, Vodafone Group wrote: -Original Message- From: Plüm, Rüdiger, Vodafone Group Sent: Donnerstag, 23. August 2012 09:55 To: dev@httpd.apache.org Subject: RE: [Vote] httpd 2.2.23 release -Original Message- From: Jeff Trawick [mailto:traw...@gmail.com] Sent: Donnerstag, 23. August 2012 03:17 To: dev@httpd.apache.org Subject: Re: [Vote] httpd 2.2.23 release On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22 Hm. Which Linux? I have never seen these on Centos 64 Bit. Perl used on Centos (5): Summary of my perl5 (revision 5 version 8 subversion 8) configuration: It should be this https://github.com/gisle/libwww-perl/commit/25f86ba92ebf3d0abcf45cfda1880a1a12a91a0b change in LWP. Changed on April 11, 2011, so probably only part of the latest LWP 6.0.3. Jeff: can you confirm the your lib is indeed this latest version 6.0.3? $ perl -MLWP -le print(LWP-VERSION) 6.04 OK, even newer. Wasn't in the tag list for LWP in their git, so I thought 6.0.3 was latest. But the suspect code is also in 6.0.4. So I'd say the test failure is a result of the above change in Perl LWP. No idea though, how the test framework could work around this. Regards, Rainer
Re: [Vote] httpd 2.2.23 release
I get the same w/ OSX 10.8 On Aug 22, 2012, at 9:16 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Aug 21, 2012 at 3:25 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... [+1] Release httpd 2.2.23 as GA I get this testing both 2.2.22 and 2.2.23 on Linux 64-bit: # Failed test 2 in t/security/CVE-2008-2364.t at line 19 # Failed test 3 in t/security/CVE-2008-2364.t at line 22
Re: [Vote] httpd 2.2.23 release
On 21.08.2012 21:25, William A. Rowe Jr. wrote: Candidate binaries are available from http://httpd.apache.org/dev/dist/ - these do not yet constitute ASF releases. Win32 specific artifacts (x86 binary distribution and -win32-src.zip) will follow sometime later this evening. Feedback and edits to the draft announcement are greatly appreciated, since we need to better position 2.2 as 'just maintenance' and we can drop some of the 'shiny new' bits of that Announcement text, given that it is old hat now, and they should be reading the 2.4 Announce (which this document now links to). So, for your consideration, a vote... +/-1 [+1] Release httpd 2.2.23 as GA Build problems: Build problems on SLES 10 when using bundled APR and OpenSSL 1.0.1c as static libs. It's due to a bug in pkg-config on SuSe Linux, which does not preserve order of -l flags when a.pc file also contains a Libs.private entry. I built a pkg-config 0.23 which contains a patch for that and the problem was gone. Not httpd's fault. Problem with configure on Linux when using external PCRE in a non-system path. configure puts -lpcre into the LIBS early and the later tests all fail, when they try to run the contest binary, because the pcre lib can not be found. IT#s a bit unfortunate, that all libs needed to build httpd are added as libs during all configure tests after the respective --with flag. Workaround is setting LD_LIBRARY_PATH just during configure. Works out of the box on Solaris, because pcre-config --libs on Solaris also outputs a -R flag. Test suite: Two failures only happen when I use a very recent LWP Perl module (version 6.0.3 and above): tests 2+3 in t/security/CVE-2008-2364.t fail, because the Perl client reads status 100 instead of 200 resp. 502. Checking our logs indicates we did send the right status codes. So this seems to be a test framework problem. Don't know how a workaround in the framework would be. Failed test 2 in t/ssl/extlookup.t and 9 in t/ssl/require.t - not a regression. Details: - win32 artefacts not checked, because not yet available - Signature and Hashes OK - key in KEYS file - gz and bz2 contents identical - no unexpected diff to svn tag - built and tested on - Solaris 8+10 Sparc - SuSE Linux Enterprise 10 (32Bit and 64Bit) - SLES 11 (64 Bit) - RedHat Enterprise Linux 5/6 64Bit - builds fine using gcc - out of tree - with all, most and default module sets - with either default (static) or shared linked modules - MPMs prefork, worker, event (where applicable) - dependencies apr/apu/expat/pcre/openssl: a) all bundled b) 1.4.6/1.4.1/2.1.0/8.30/1.0.1c - configure fails for external non system pcre (see above) - test suite ran for all those builds with log levels info and debug - no test regressions w.r.t. at least 2.2.16-2.2.22: - Failed test 2 in t/ssl/extlookup.t at line 27 - Failed test 9 in t/ssl/require.t at line 44 For details about both see my 2.2.19 voting mail. - Failed tests 2+3 in t/security/CVE-2008-2364.t when using LWP 6.0.3 or above Regards, Rainer
Re: Ideas for an output filter for mod_lua
On 23 Aug 2012, at 11:45, Daniel Gruno rum...@cord.dk wrote: On 08/23/2012 12:02 AM, Tim Bannister wrote: I don't know if this is another way of phrasing Nick's question or not, but would I be able to implement gzip Transfer-Encoding: just using Lua and this new directive? I found (bug 52860) it a bit tricky to achieve in C, so I think it could be harder still with the extra limitations of the Lua environment. My C code uses AP_FTYPE_TRANSCODE which I think is the right choice but few modules get involved at this filtering stage. … So yes, theoretically you should be able to implement decompression this way, by doing something along the lines of this (totally just making it up): - local zip = require zlib -- or something... function gzip_handle(r) r.headers_out['Transfer-Encoding'] = gzip -- or ? do_magic_header_stuff_here() -- add header data coroutine.yield() -- yield and wait for buckets while (buffer) do -- for each bucket, deflate it local deflated = zip.deflate(buffer) coroutine.yield(deflated) -- pass on new data end append_tail_to_output() -- pass on a tail if needed end - My patch is for implementing gzip compression by httpd, not decompression, but the code will look pretty similar. That's quite neat, then. I will try to make an actual implementation in Lua. The part I found difficult was the interaction with the second transfer-encoding, “chunked”. Using gzip Transfer-Encoding: implies using chunked, because we want to shorten the response and this means that the Content-Length definitely doesn't match the size of the HTTP response body. -- Tim Bannister – is...@jellybaby.net smime.p7s Description: S/MIME cryptographic signature
Update on your 2.2 RM
Sorry, I'm not ignoring the list (entirely). Seems Thunderbird and my ISP have decided not to dance anymore and it looks like I'm spending Thursday doing some fundamental email restructuring (sigh). Hopefully I'll have the list traffic back sometime by Friday, thanks to Jeff, Reindl, and Steffen for your review, I didn't read Ruediger, Rainer, or Jim as voting one way or another - even with my vote there is still a missing PMC +1 for release. Rainer, are your observations a regression? Because the security issues are relatively minor, I took this opportunity to update to a slightly refreshed autoconf (not a radically new version, nor the last in that version minor which barfs on our configure.in and m4 files)... so it's possible I had introduced this. If not a regression, please confirm.
Re: Ideas for an output filter for mod_lua
On Thu, 23 Aug 2012 22:32:20 +0100 Tim Bannister is...@jellybaby.net wrote: That's quite neat, then. I will try to make an actual implementation in Lua. The part I found difficult was the interaction with the second transfer-encoding, “chunked”. Using gzip Transfer-Encoding: implies using chunked, because we want to shorten the response and this means that the Content-Length definitely doesn't match the size of the HTTP response body. gzip is a content-encoding, not a transfer-encoding. That makes it easy to implement: content filters and protocol filters work at different levels, so can coexist without trouble. -- Nick Kew
Re: Ideas for an output filter for mod_lua
On Aug 23, 2012, at 2:49 PM, Nick Kew wrote: On Thu, 23 Aug 2012 22:32:20 +0100 Tim Bannister is...@jellybaby.net wrote: That's quite neat, then. I will try to make an actual implementation in Lua. The part I found difficult was the interaction with the second transfer-encoding, “chunked”. Using gzip Transfer-Encoding: implies using chunked, because we want to shorten the response and this means that the Content-Length definitely doesn't match the size of the HTTP response body. gzip is a content-encoding, not a transfer-encoding. It is both. Transfer-Encoding is the correct way to implement it. That makes it easy to implement: content filters and protocol filters work at different levels, so can coexist without trouble. Except that they aren't standards-compliant because they don't handle etags correctly. Content-Encoding works with more clients but is much harder to implement correctly. Roy
Re: Update on your 2.2 RM
On 23.08.2012 23:44, William A. Rowe Jr. wrote: Sorry, I'm not ignoring the list (entirely). Seems Thunderbird and my ISP have decided not to dance anymore and it looks like I'm spending Thursday doing some fundamental email restructuring (sigh). Hopefully I'll have the list traffic back sometime by Friday, thanks to Jeff, Reindl, and Steffen for your review, I didn't read Ruediger, Rainer, or Jim as voting one way or another - even with my vote there is still a missing PMC +1 for release. Rainer, are your observations a regression? Because the security issues are relatively minor, I took this opportunity to update to a slightly refreshed autoconf (not a radically new version, nor the last in that version minor which barfs on our configure.in and m4 files)... so it's possible I had introduced this. If not a regression, please confirm. I found no regressions. Looks fine, voted +1. Regards, Rainer
Re: [Vote] httpd 2.2.23 release
+1 AIX/XLC/PPC64
