Re: Reducing number of mod_lua hook directives
On Mon, May 10, 2010 at 2:03 PM, William A. Rowe Jr.
wrote:
> On 5/10/2010 2:25 PM, Brian McCallister wrote:
>>> ...
>>>
>>> to
>>>
>>> LuaHook AccessChecker /path/to/script.lua funcname
>>> LuaHook AuthChecker /path/to/script.lua funcname
>>> LuaHook CheckUserID /path/to/script.lua funcname
>
> Any reason not to name the func before the script, especially since path names
> can get long winded, and I'm thinking C like decl funcname(args) {script}
That makes a lot of sense as well, actually.
>
Re: Solving util_mutex pain?
+1 from me tests good (thx for the reminder ping!) On May 10, 2010, at 4:35 PM, William A. Rowe Jr. wrote: > On 5/4/2010 2:16 PM, William A. Rowe Jr. wrote: >> Here's a backport vote to 2.2 for your consideration; >> >> It is far too painful to adopt the new Mutex directive for modules targeting >> httpd 2.2 and future 2.3. The solution, I believe, is to provide the mutex >> directive for all developers to use, and simply not adopt it within httpd >> itself >> until our jump to 2.4 happens. >> >> To that end, I've hacked together >> http://people.apache.org/~wrowe/mod_mutex.c >> http://people.apache.org/~wrowe/util_mutex.h >> which I'm propose we adopt for inclusion in both our httpd 2.2 and 2.0 trees >> under >> 'experimental/', and default to build 'most' (effectively, an ever present >> no-op, >> until they add an external module that relies on it). >> >> If this is accepted, it would become a prereq for users adopting new releases >> of mod_fcgid or mod_ftp. You can review the source code to see how badly we >> need a simpler solution; >> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_mutex_unix.c?view=markup&pathrev=885868 >> - of course the user of a slightly >> older 2.2.x or 2.0.x could simply build mod_mutex with apxs and then their >> module, >> and they also must install util_mutex.h for dependent module builds to >> succeed. >> >> So please review and opine... >> >> +/-1 >> [ ] Adopt mod_mutex.c on httpd 2.2.x svn branch >> [ ] Adopt mod_mutex.c on httpd 2.0.x svn branch > > Any further votes? FWIW there is a new rev .1 of the .h file that changes the > unused data members into unused static functions. All my compilers apparently > have no problems with the later. > > http://people.apache.org/~wrowe/util_mutex.h.1 >
Re: Solving util_mutex pain?
On 5/4/2010 2:16 PM, William A. Rowe Jr. wrote: > Here's a backport vote to 2.2 for your consideration; > > It is far too painful to adopt the new Mutex directive for modules targeting > httpd 2.2 and future 2.3. The solution, I believe, is to provide the mutex > directive for all developers to use, and simply not adopt it within httpd > itself > until our jump to 2.4 happens. > > To that end, I've hacked together > http://people.apache.org/~wrowe/mod_mutex.c > http://people.apache.org/~wrowe/util_mutex.h > which I'm propose we adopt for inclusion in both our httpd 2.2 and 2.0 trees > under > 'experimental/', and default to build 'most' (effectively, an ever present > no-op, > until they add an external module that relies on it). > > If this is accepted, it would become a prereq for users adopting new releases > of mod_fcgid or mod_ftp. You can review the source code to see how badly we > need a simpler solution; > http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/modules/fcgid/fcgid_mutex_unix.c?view=markup&pathrev=885868 > - of course the user of a slightly > older 2.2.x or 2.0.x could simply build mod_mutex with apxs and then their > module, > and they also must install util_mutex.h for dependent module builds to > succeed. > > So please review and opine... > > +/-1 > [ ] Adopt mod_mutex.c on httpd 2.2.x svn branch > [ ] Adopt mod_mutex.c on httpd 2.0.x svn branch Any further votes? FWIW there is a new rev .1 of the .h file that changes the unused data members into unused static functions. All my compilers apparently have no problems with the later. http://people.apache.org/~wrowe/util_mutex.h.1
Re: Reducing number of mod_lua hook directives
On 5/10/2010 2:25 PM, Brian McCallister wrote:
>> ...
>>
>> to
>>
>> LuaHook AccessChecker /path/to/script.lua funcname
>> LuaHook AuthChecker /path/to/script.lua funcname
>> LuaHook CheckUserID /path/to/script.lua funcname
Any reason not to name the func before the script, especially since path names
can get long winded, and I'm thinking C like decl funcname(args) {script}
Re: Reducing number of mod_lua hook directives
+1 ~Jorge On Mon, May 10, 2010 at 9:41 PM, Jeff Trawick wrote: > On Mon, May 10, 2010 at 3:25 PM, Brian McCallister > wrote: > > On Mon, May 10, 2010 at 11:02 AM, Dan Poirier wrote: > >> mod_lua has 8 separate directives for adding hooks using external files > >> with Lua code (LuaHookX) and 8 more for adding the same hooks using > >> inline Lua code (). Most of the code to implement these > >> is common. > >> > >> I think it'd be easier to understand - and document - the module if we > >> cut these down to two directives, with an additional argument to > >> indicate which hook is involved. E.g. change > >> > >> LuaHookAccessChecker /path/to/script.lua funcname > >> LuaHookAuthChecker /path/to/script.lua funcname > >> LuaHookCheckUserID /path/to/script.lua funcname > >> ... > >> > >> to > >> > >> LuaHook AccessChecker /path/to/script.lua funcname > >> LuaHook AuthChecker /path/to/script.lua funcname > >> LuaHook CheckUserID /path/to/script.lua funcname > > > > This makes a ton of sense to me. > > +1 >
Re: Reducing number of mod_lua hook directives
On Mon, May 10, 2010 at 3:25 PM, Brian McCallister wrote: > On Mon, May 10, 2010 at 11:02 AM, Dan Poirier wrote: >> mod_lua has 8 separate directives for adding hooks using external files >> with Lua code (LuaHookX) and 8 more for adding the same hooks using >> inline Lua code (). Most of the code to implement these >> is common. >> >> I think it'd be easier to understand - and document - the module if we >> cut these down to two directives, with an additional argument to >> indicate which hook is involved. E.g. change >> >> LuaHookAccessChecker /path/to/script.lua funcname >> LuaHookAuthChecker /path/to/script.lua funcname >> LuaHookCheckUserID /path/to/script.lua funcname >> ... >> >> to >> >> LuaHook AccessChecker /path/to/script.lua funcname >> LuaHook AuthChecker /path/to/script.lua funcname >> LuaHook CheckUserID /path/to/script.lua funcname > > This makes a ton of sense to me. +1
Re: Reducing number of mod_lua hook directives
On Mon, May 10, 2010 at 11:02 AM, Dan Poirier wrote: > mod_lua has 8 separate directives for adding hooks using external files > with Lua code (LuaHookX) and 8 more for adding the same hooks using > inline Lua code (). Most of the code to implement these > is common. > > I think it'd be easier to understand - and document - the module if we > cut these down to two directives, with an additional argument to > indicate which hook is involved. E.g. change > > LuaHookAccessChecker /path/to/script.lua funcname > LuaHookAuthChecker /path/to/script.lua funcname > LuaHookCheckUserID /path/to/script.lua funcname > ... > > to > > LuaHook AccessChecker /path/to/script.lua funcname > LuaHook AuthChecker /path/to/script.lua funcname > LuaHook CheckUserID /path/to/script.lua funcname This makes a ton of sense to me. > ... > > > and > > > -- lua code > > > to > > > -- lua code > > > > Thoughts? > > Dan > >
Re: FixedInTrunk keyword?
On 5/10/2010 1:28 PM, Daniel Ruggeri wrote: > Hi, all. > I found this document today stating the following: > Each developer is responsible for notifying the mailing list and > adding an action item to STATUS when they have an idea for a new feature > or major change to propose for the product. > Since I am not a committer, how would I go about having my submitted > patch added to the STATUS file in the 2.2 branch after it has been > "FixedInTrunk"? Just post a patch to the dev@ list. The plain text would be fine by me, but you want to ensure any committer can patch STATUS for you, no matter which workflow they use.
Re: FixedInTrunk keyword?
Hi, all. I found this document today stating the following: Each developer is responsible for notifying the mailing list and adding an action item to STATUS when they have an idea for a new feature or major change to propose for the product. Since I am not a committer, how would I go about having my submitted patch added to the STATUS file in the 2.2 branch after it has been "FixedInTrunk"? Thanks -Daniel Ruggeri Daniel Ruggeri wrote: > Sander/All; > Oh, I see. I guess my next question is how the issue fixed in trunk gets proposed in the STATUS list. I submitted a patch that was added to trunk, but am unsure if there is any additional action to take on my part. > > P.S. > Also, is this information or process noted anywhere? I apologize for polluting the general mailing list with basic process questions. > > -- > Daniel Ruggeri > > > Sander Temme wrote: >> On Apr 20, 2010, at 12:41 PM, Daniel Ruggeri wrote: >> >> >>> Hi all; >>> I have a little confusion regarding the FixedInTrunk keyword when applied to a bug. What does it mean? My assumption is that it means that the code changes needed to fix the bug have been committed to the source repository and the fix will be available in the next stable release. Once that happens, the bug will be closed. Is this accurate? >>> >> >> That's not how I read it. The current stable releases are taken from the 2.2.x branch. Issues fixed in trunk are proposed for backport in the STATUS file: >> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS >> >> and backported once they collect the requisite three +1 votes. >> A FixedInTrunk keyword would allow you to take the fix and backport it on your own, ahead of any activity by the httpd project, should you have a need to do so. >> S. >> >> >>> Thank you for your time answering my simple question >>> -Daniel Ruggeri
[SPAM] test + apology
Spam detection software, running on the system "heartofgold.mirimar.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: My SpamAssassin was quirky earlier - wanted to apologize for the noise (and make sure it doesn't happen again now) Issac [...] Content analysis details: (5.5 points, 5.0 required) pts rule name description -- -- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0005] 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [79.183.201.141 listed in bb.barracudacentral.org] 3.3 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL [79.183.201.141 listed in zen.spamhaus.org] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 1.0 TO_NO_BRKTS_DYNIP TO_NO_BRKTS_DYNIP --- Begin Message --- My SpamAssassin was quirky earlier - wanted to apologize for the noise (and make sure it doesn't happen again now) Issac --- End Message ---
[SPAM] Re: Reducing number of mod_lua hook directives
Spam detection software, running on the system "heartofgold.mirimar.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: On 5/10/2010 8:02 PM, Dan Poirier wrote: > mod_lua has 8 separate directives for adding hooks using external files > with Lua code (LuaHookX) and 8 more for adding the same hooks using > inline Lua code (). Most of the code to implement these > is common. > > I think it'd be easier to understand - and document - the module if we > cut these down to two directives, with an additional argument to > indicate which hook is involved. E.g. change > [snip] > > > Thoughts? > > Dan > Maybe so, and maybe no... The mod_perl community, for example, has all of these names. It makes it easier for newbies to distinguish between the directives, I think. But maybe I'm biased because I got "into" the C API coming from mod_perl... [...] Content analysis details: (5.5 points, 5.0 required) pts rule name description -- -- 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [79.183.201.141 listed in bb.barracudacentral.org] 3.3 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL [79.183.201.141 listed in zen.spamhaus.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 1.0 TO_NO_BRKTS_DYNIP TO_NO_BRKTS_DYNIP --- Begin Message --- On 5/10/2010 8:02 PM, Dan Poirier wrote: mod_lua has 8 separate directives for adding hooks using external files with Lua code (LuaHookX) and 8 more for adding the same hooks using inline Lua code (). Most of the code to implement these is common. I think it'd be easier to understand - and document - the module if we cut these down to two directives, with an additional argument to indicate which hook is involved. E.g. change [snip] Thoughts? Dan Maybe so, and maybe no... The mod_perl community, for example, has all of these names. It makes it easier for newbies to distinguish between the directives, I think. But maybe I'm biased because I got "into" the C API coming from mod_perl... Just my $0.02, Issac --- End Message ---
Reducing number of mod_lua hook directives
mod_lua has 8 separate directives for adding hooks using external files with Lua code (LuaHookX) and 8 more for adding the same hooks using inline Lua code (). Most of the code to implement these is common. I think it'd be easier to understand - and document - the module if we cut these down to two directives, with an additional argument to indicate which hook is involved. E.g. change LuaHookAccessChecker /path/to/script.lua funcname LuaHookAuthChecker /path/to/script.lua funcname LuaHookCheckUserID /path/to/script.lua funcname ... to LuaHook AccessChecker /path/to/script.lua funcname LuaHook AuthChecker /path/to/script.lua funcname LuaHook CheckUserID /path/to/script.lua funcname ... and -- lua code to -- lua code Thoughts? Dan
mod_include.c with ap_rflush
Hi,
I have developed an tested a mod_include.c improvement (httpd 2.2.15).
The module can now handle the "include uvirtual" command, where "uvirtual"
means "unbuffered".
If command is "include virtual" and 200 OK there is a call to ap_rflush(r).
I had this idea because is useful to send chunk (also with gzip) in a
controlled way to force the browser rendering with simple html files! Yes I
love static files ;-)
Scenario:
1 html file with 3 includes, nested included not tested now.
Browsers behavior:
* Chrome and Safari (also with iPhone) need more bytes before starting the
render task.
* Explorer 8 and Firefox are ok with a few bytes.
Here is an .html example:
The header comes first and then (4 seconds later) the content.
I'd love any feedback!
Massimiliano Pinto
IT Specialist
Banzai Consulting s.r.l.
Milan, ITALY
P.S:
here is the patch
Index: httpd-trunk/modules/filters/mod_include.c
===
--- httpd-trunk/modules/filters/mod_include.c (revision 942722)
+++ httpd-trunk/modules/filters/mod_include.c (working copy)
@@ -1060,8 +1060,9 @@
if (!tag || !tag_val) {
break;
}
-
-if (strcmp(tag, "virtual") && strcmp(tag, "file")) {
+
+ /* added uvirtual for unbuffered include virtual */
+if (strcmp(tag, "virtual") && strcmp(tag, "file") && strcmp(tag,
"uvirtual")) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "unknown parameter "
"\"%s\" to tag include in %s", tag, r->filename);
SSI_CREATE_ERROR_BUCKET(ctx, f, bb);
@@ -1130,6 +1131,11 @@
if (error_fmt) {
break;
}
+
+/* if all ok and tag is uvirtual do the flush! */
+if (tag[0] == 'u') {
+ap_rflush(r);
+}
}
return APR_SUCCESS;
mod_ssl, SNI and dynamic virtual hosts
We have a setup that uses an in-house module which works not entirely unlike mod_vhost_alias, in that it has a single virtual host configured, and then determines stuff like domain name, docroot, etc, from the request. We'd love to be able to use SSL in this setup, but as far as I can see, the only way to do this would be to change (i.e. hack) mod_ssl to do the certificate loading sometime around request-time, since the apache server and SSL have no clue what virtual hosts they will be serving at startup. How would such a hack, if at all possible, affect stuff like certificate caching and other things? I'd love any feedback! -- Adam Hasselbalch Hansen UNIX Systems Developer, CPH e: a...@one.com, w: www.one.com
