Re: Time for 2.4.5
Am 24.06.2013 20:16, schrieb Jim Jagielski: I propose a release somewhere around the 4th of July, to celebrate our independence from proprietary s/w! I'll RM a snapshot for testers at http://httpd.apache.org/dev/dist/ would be fine, it would take me 5 minutes to rebuild our RPM from it and i guess other people too signature.asc Description: OpenPGP digital signature
Re: Time for 2.4.5 ??
That is true actually, new test system - will need to look at why 2.4.4 stumbled over that, while 2.4.x did not. Many thanks for the feedback. On Fri, Jun 7, 2013 at 12:00 AM, Eric Covener cove...@gmail.com wrote: On Thu, Jun 6, 2013 at 5:56 PM, Michael Felt mamf...@gmail.com wrote: consider this a curiosity - but using the same configure command for 2.4.4 and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec in version 2.4.4, but not in 2.4.x Is this expected? the mod_deflate.so is no longer included (by default)? Maybe your current env doesn't find zlib/zlib headers? Check config.log.
Re: Time for 2.4.5 ??
consider this a curiosity - but using the same configure command for 2.4.4 and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec in version 2.4.4, but not in 2.4.x Is this expected? the mod_deflate.so is no longer included (by default)? using: ./configure \ --enable-layout=$LAYOUT \ --with-apr=$apr_config \ --with-apr-util=$apu_config \ --enable-mpms-shared=all \ --enable-mods-shared=all \ --disable-lua is what I use to configure 2.4.X for AIX note: there are also some additions, but I am mainly curious about what does not get built, but the source still exists. On Mon, Jun 3, 2013 at 7:47 PM, Shahid khan slappy...@gmail.com wrote: On Jun 3, 2013 11:11 PM, Michael Felt mamf...@gmail.com wrote: I have meanwhile all the compiler warnings reduced down to one: .\lua_request.c(574) : warning C4244: 'return' : conversion from 'apr_off_t' to 'int', possible loss of data Nice work! :)
Re: Time for 2.4.5 ??
On Thu, Jun 6, 2013 at 5:56 PM, Michael Felt mamf...@gmail.com wrote: consider this a curiosity - but using the same configure command for 2.4.4 and 2.4.x - with 2.4.x the filter mod_deflate.c gets included in libexec in version 2.4.4, but not in 2.4.x Is this expected? the mod_deflate.so is no longer included (by default)? Maybe your current env doesn't find zlib/zlib headers? Check config.log.
Re: Time for 2.4.5 ??
I have meanwhile all the compiler warnings reduced down to one: .\lua_request.c(574) : warning C4244: 'return' : conversion from 'apr_off_t' to 'int', possible loss of data Nice work! :)
Re: Time for 2.4.5 ??
On Jun 3, 2013 11:11 PM, Michael Felt mamf...@gmail.com wrote: I have meanwhile all the compiler warnings reduced down to one: .\lua_request.c(574) : warning C4244: 'return' : conversion from 'apr_off_t' to 'int', possible loss of data Nice work! :)
Re: Time for 2.4.5 ??
On 25.05.2013 05:46, Guenter Knauf wrote: Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5 local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5' the function call should here be r:unescape(url) ... another one missing from the docs: r:construct_url(string) -- Constructs an URL from an URI local url = r:construct_url(r.uri) Gün.
Re: Time for 2.4.5 ??
Can some of the proposed backports lacking a single vote get sum luv?
Re: Time for 2.4.5 ??
Hi Daniel,
On 25.05.2013 05:46, Guenter Knauf wrote:
On 25.05.2013 02:06, Guenter Knauf wrote:
On 24.05.2013 23:45, Daniel Gruno wrote:
That's fine by me, I'm not married to 'sleep' (although I do like a good
nap)
hehe, ok; I look into it soon.
done.
Found another small docu bug:
r:unescape(string) -- Unescapes an URL-escaped string:
local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5
local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5'
the function call should here be r:unescape(url) ...
I have meanwhile all the compiler warnings reduced down to one:
.\lua_request.c(574) : warning C4244: 'return' : conversion from
'apr_off_t' to 'int', possible loss of data
this is a somehwat tricky one, and I'm not sure whats the best way to
fix it; clearly a cast wouldnt help here since r-remaining is
apr_off_t, so a cast to int would indeed be a loss of data ...
so the function needs to return the 64-bit apr_off_t:
Index: lua_request.c
===
--- lua_request.c (revision 1486269)
+++ lua_request.c (working copy)
@@ -569,7 +569,7 @@
return r-useragent_ip;
}
-static int req_remaining_field(request_rec *r)
+static apr_off_t req_remaining_field(request_rec *r)
{
return r-remaining;
}
but then the problem would be shifted to req_dispatch() where we only
have APL_REQ_FUNTYPE_INT - should we add there a new type
APL_REQ_FUNTYPE_INT64? Or do you have a better idea?
Gün.
Re: Time for 2.4.5 ??
On May 24, 2013, at 4:22 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On Wed, 22 May 2013 14:20:03 -0400 Jim Jagielski j...@jagunet.com wrote: I would be nice, imo, to start thinking about a 2.4.5 release Real Soon Now. We have lots of stuff added and fixed in 2.4.5-dev and even more fun stuff in STATUS. I'll RM. What is your thought on RSN? I was thinking a TR sometime next week.
Re: Time for 2.4.5 ??
On Wed, May 22, 2013 at 02:20:03PM -0400, Jim Jagielski wrote: I would be nice, imo, to start thinking about a 2.4.5 release Real Soon Now. We have lots of stuff added and fixed in 2.4.5-dev and even more fun stuff in STATUS. Let me again ask for backports of r1368121, r1388447 and r1389339 from trunk; they are required to build mpm-itk without patching Apache. Surely when it is acceptable to copy all of mod_ssl from trunk, it must be possible to add three small hooks? :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Time for 2.4.5 ??
On 28 May 2013, at 3:33 PM, Steinar H. Gunderson sgunder...@bigfoot.com wrote: Let me again ask for backports of r1368121, r1388447 and r1389339 from trunk; they are required to build mpm-itk without patching Apache. Proposed. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Time for 2.4.5 ??
On Tue, May 28, 2013 at 04:14:55PM +0200, Graham Leggett wrote: Let me again ask for backports of r1368121, r1388447 and r1389339 from trunk; they are required to build mpm-itk without patching Apache. Proposed. Thanks! /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Time for 2.4.5 ??
+ is not used in url-encoding. + is used in application/x-www-form-urlencoded encoding. So I assume this function has implemented unescaping application/x-www-form-urlencoded. For regular URL-encoding, space is encoded as %20. On Fri, May 24, 2013 at 11:46 PM, Guenter Knauf fua...@apache.org wrote: Hi Daniel, On 25.05.2013 02:06, Guenter Knauf wrote: On 24.05.2013 23:45, Daniel Gruno wrote: That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. done. Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+**%26+4+%2b+5 local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5' the function call should here be r:unescape(url) ... Gün.
Re: Time for 2.4.5 ??
There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) o Performance-related patches (Event mod_ssl, cache, etc)
Re: Time for 2.4.5 ??
On Fri, May 24, 2013 at 8:40 AM, Jim Jagielski j...@jagunet.com wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) Could you provide some notes for testing wstunnel in a real-world scenario? Thanks! o Performance-related patches (Event mod_ssl, cache, etc) -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Time for 2.4.5 ??
On 24.05.2013 14:40, Jim Jagielski wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff ok, after spending a bunch of hours during last weeks with testing mod_lua mainly on Windows I've finally removed my blocking vote from STATUS just now; nevertheless I feel that I did only test half of all the new stuff, and therefore my vote is +0.5 only ... some things which I see as outstanding are: - removal of the export declarations since they are unneeded (I will take a look into this during this weekend if nobody beats me) - removal of some doubled code ( ap_lua_check_request_rec() ) - another docu fix for r:sleep() -- r.sleep(); meanwhile I have a stronger oppinion about this: I believe we should chage all functions to r:function() in order to separate them more clearly from vars like r.filename; further more I believe r.sleep() would be better renamed to r.usleep() taking microseconds instead of having a r.sleep() and then dealing with fractions of seconds - this way also the code would be cleaner and no calculation of the passed-in value needed anymore, just the value would get passed to apr_sleep(). Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... So how do we further proceed with mod_lua? There are certainly some remaining issues, but it just takes too long for only 2 persons to find them all; also I see with current code that it works fine when I compile it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not sure yet if this is an issue with MSVC9 itself, or with the converted projects ...; I think we should now copy over the complete trunk code to 2.4.x branch, and keep the status 'experimental' so that users are warned that directives, functions, etc. might change even with an otherwise stable release branch; hopefully then when more users play with mod_lua we will make faster progress with finding any further issues ... also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. Gün.
Re: Time for 2.4.5 ??
On Fri, 24 May 2013 21:02:04 +0200 Guenter Knauf fua...@apache.org wrote: also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing.
Re: Time for 2.4.5 ??
On Wed, 22 May 2013 14:20:03 -0400 Jim Jagielski j...@jagunet.com wrote: I would be nice, imo, to start thinking about a 2.4.5 release Real Soon Now. We have lots of stuff added and fixed in 2.4.5-dev and even more fun stuff in STATUS. I'll RM. What is your thought on RSN? Sometime Thurs-Sat timeframe late next week? It could be good to have a goal and then slip the whole thing 1 week exactly if we can't reach it. My schedule is now very flexible, so you choose :) I like the late-week roll so that weekday coders and weekend warriors can both put their hands on the candidate.
Re: Time for 2.4.5 ??
On 24 May 2013, at 2:40 PM, Jim Jagielski j...@jagunet.com wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff o the Websocket Proxy module (wstunnel) o Performance-related patches (Event mod_ssl, cache, etc) Pretty much all of the cache and proxy related proposals are fixes for RFC violations, detected courtesy of the CoAdvisor test suite. It would be goodness to get these out there. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: Time for 2.4.5 ??
On 24.05.2013 22:14, William A. Rowe Jr. wrote: There are several others of us, but large patch sets are difficult to incorporate in our day-to-day build trees. What about a sandbox of all of the proposed deltas, either just the modules/lua/ branch or the entire tree if that isn't realistic. It's preferable to just svn switch that branch to the sandbox for some more active eyeballs looking at the thing. ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. Gün.
Re: Time for 2.4.5 ??
On 05/24/2013 09:02 PM, Guenter Knauf wrote: On 24.05.2013 14:40, Jim Jagielski wrote: There are a few things I'd like to see in 2.4.5, which would be significant for the 2.4.x release: o The mod_lua stuff ok, after spending a bunch of hours during last weeks with testing mod_lua mainly on Windows I've finally removed my blocking vote from STATUS just now; nevertheless I feel that I did only test half of all the new stuff, and therefore my vote is +0.5 only ... some things which I see as outstanding are: - removal of the export declarations since they are unneeded (I will take a look into this during this weekend if nobody beats me) - removal of some doubled code ( ap_lua_check_request_rec() ) - another docu fix for r:sleep() -- r.sleep(); meanwhile I have a stronger oppinion about this: I believe we should chage all functions to r:function() in order to separate them more clearly from vars like r.filename; I can only say +1 from me, we need consistency here :) further more I believe r.sleep() would be better renamed to r.usleep() taking microseconds instead of having a r.sleep() and then dealing with fractions of seconds - this way also the code would be cleaner and no calculation of the passed-in value needed anymore, just the value would get passed to apr_sleep(). That's fine by me, I'm not married to 'sleep' (although I do like a good nap) Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? So how do we further proceed with mod_lua? There are certainly some remaining issues, but it just takes too long for only 2 persons to find them all; also I see with current code that it works fine when I compile it with MSVC6 while compiled MSVC9 it crashes when things go wrong - not sure yet if this is an issue with MSVC9 itself, or with the converted projects ...; I ran into some issues with MSVC10/11, but they appear to have been fixed (though not 100% sure) - but I'm not a big Windows expert anymore :| I think we should now copy over the complete trunk code to 2.4.x branch, and keep the status 'experimental' so that users are warned that directives, functions, etc. might change even with an otherwise stable release branch; hopefully then when more users play with mod_lua we will make faster progress with finding any further issues ... also given that currently only Daniel and I (and Gregg with some testing) care about mod_lua I would like that we make an exception for this module so that we can backport any further modifications and fixes directly to the 2.4.x branch until we declare the module as stable and non-experimental. Gün. With regards, Daniel.
Re: Time for 2.4.5 ??
Hi Daniel, On 24.05.2013 23:45, Daniel Gruno wrote: I can only say +1 from me, we need consistency here :) great! That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. Optional: I really would like to also have DBM support in addition to the DBD support, but unfortunately I had not the time yet to look into it ... I've not looked in APR, but I assume this is something supported in there? Perhaps if you could come up with a sketch/mock api, we could get started on this? yes, see the apr_dbm.h header; SDBM is the only database we allways have even without any driver or external libs; it can be used f.e. for password storage (htdbm.c), and I think mod_dav makes use of it for its lock database; as usage example might serve mod_authn_dbm.c ... Gün.
Re: Time for 2.4.5 ??
Hi Daniel, On 25.05.2013 02:06, Guenter Knauf wrote: On 24.05.2013 23:45, Daniel Gruno wrote: That's fine by me, I'm not married to 'sleep' (although I do like a good nap) hehe, ok; I look into it soon. done. Found another small docu bug: r:unescape(string) -- Unescapes an URL-escaped string: local url = http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5 local unescaped = r:escape(url) -- returns 'http://foo.bar/1 2 3 4 + 5' the function call should here be r:unescape(url) ... Gün.
Re: Time for 2.4.5 ??
On 5/24/2013 2:03 PM, Guenter Knauf wrote: ATM I think this is not needed - from what I tested during past weeks the current trunk code is at least as good / bad as what is already in 2.4.x branch - so copying over trunk to 2.4.x seems an improvement to me due to various bug fixes beside the added new stuff. I'm +1 to this approach.
Re: Time for 2.4.5 ??
On Wed, 22 May 2013 14:20:03 -0400 Jim Jagielski j...@jagunet.com wrote: I would be nice, imo, to start thinking about a 2.4.5 release Real Soon Now. We have lots of stuff added and fixed in 2.4.5-dev and even more fun stuff in STATUS. I'll RM. +1 and once this head-cold is clear, I'm now seeing daylight ahead and have cycles to RM our 'final' 2.0.65 and a freshened 2.2.25 using their most recent respective toolchains. That should put 2.0 to bed and catch 2.2 up with the rewrite log escaping.
