Re: FixedInTrunk keyword?
On May 10, 2010, at 11:36 AM, William A. Rowe Jr. wrote: > 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"? Speaking for myself only, we seem to have an interesting symbiosis with Bugzilla. We all agree it's necessary to have a formal issue tracker, but the informal discussion on dev@ often works faster and smoother. > 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. I agree with wrowe. Check out http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x and edit STATUS. See the existing backport proposals for guidance on formatting. Then run svn diff STATUS and send the result to the list. If the backported patch materially differs from the revision changes in trunk, I'd suggest either publishing a patch against 2.2.x HEAD somewhere (anywhere) or attaching it to your patch for STATUS. S. -- Sander Temme scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Reducing number of mod_lua hook directives
On 5/11/2010 9:47 AM, Dan Poirier wrote: >> >> LuaHook AccessChecker funcname /path/to/script.lua > > I just thought of a problem - right now, the funcname is optional > (defaults to "handle"). I hate having optional arguments that don't > come at the end. I'd just as soon make it a required argument, but if > people would rather it stay optional, then I'd rather leave it at the > end. What do folks prefer? I don't think this really violates the principal of adding optargs at the end of the directive. func names and paths appear sufficiently different.
Re: Reducing number of mod_lua hook directives
On 2010-05-11 at 12:59, "Akins, Brian" wrote: > The hook runner itself should just be in lua. Instead of scripts, you write > lua modules. If a lua module has a function with the correct names (ie, > same as hooks) it uses that: > > Ie in my module foo > > function fixups( r ) > > > > Would get called at fixups, etc. > > > No need for a state per file, etc. Just have one state per thread. That sounds like a bigger change to how everything works. So we'd just associate a Lua module with a configuration context, then any functions defined in that module with names the same as hooks would get invoked in those request phases? Even if we don't go that far, I like the idea of just naming the functions the same as the hooks, and not cluttering the configuration with function names that most people will probably make the same as the hook names anyway. Maybe we should just drop the function names from the configuration.
Re: Reducing number of mod_lua hook directives
On Tue, May 11, 2010 at 20:12, Dan Poirier wrote: > On 2010-05-11 at 12:55, HyperHacker wrote: >> On Tue, May 11, 2010 at 08:47, Dan Poirier wrote: >>> I just thought of a problem - right now, the funcname is optional >>> (defaults to "handle"). I hate having optional arguments that don't >>> come at the end. I'd just as soon make it a required argument, but if >>> people would rather it stay optional, then I'd rather leave it at the >>> end. What do folks prefer? >> >> I'd go for making it required, but is there a reason you have to >> specify a function? Lua scripts usually start executing from the first >> line in the file. It seems to me to make more sense to do that if a >> function is not specified (or is "-" if it's a required argument). > > The request object is passed to the function as an argument, so there > would have to be some other way to give the Lua code access to the > request. > Say, the global variable Request or Server.Request? -- Sent from my toaster.
Re: Reducing number of mod_lua hook directives
On 2010-05-11 at 12:55, HyperHacker wrote: > On Tue, May 11, 2010 at 08:47, Dan Poirier wrote: >> I just thought of a problem - right now, the funcname is optional >> (defaults to "handle"). I hate having optional arguments that don't >> come at the end. I'd just as soon make it a required argument, but if >> people would rather it stay optional, then I'd rather leave it at the >> end. What do folks prefer? > > I'd go for making it required, but is there a reason you have to > specify a function? Lua scripts usually start executing from the first > line in the file. It seems to me to make more sense to do that if a > function is not specified (or is "-" if it's a required argument). The request object is passed to the function as an argument, so there would have to be some other way to give the Lua code access to the request.
Re: svn commit: r942899 - /httpd/httpd/branches/2.2.x/STATUS
Hi Stefan, WRT Windows, E:\build\httpd-2.2.x-dev\modules\filters\mod_reqtimeout.c(154) : error C2065: 'core_module' : undeclared identifier E:\build\httpd-2.2.x-dev\modules\filters\mod_reqtimeout.c(154) : error C2223: left of '->module_index' must point to struct/union Regards, Gregg s...@apache.org wrote: Author: sf Date: Mon May 10 20:54:05 2010 New Revision: 942899 URL: http://svn.apache.org/viewvc?rev=942899&view=rev Log: propose Modified: httpd/httpd/branches/2.2.x/STATUS Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=942899&r1=942898&r2=942899&view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Mon May 10 20:54:05 2010 @@ -151,6 +151,27 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: 2.2.x patch: http://people.apache.org/~sf/log_cookie_28037.diff +1: sf + * mod_req-timeout/core: Backport bugfixes from trunk up to r935339: +- Do not wrongly enforce timeouts for mod_proxy's backend + connections and other protocol handlers (like mod_ftp). +- Enforce the timeout for AP_MODE_GETLINE. +- If there is a timeout, shorten the lingering close time from 30 to + 2 seconds (involves a change in the core). +Trunk patch: http://svn.apache.org/viewvc?rev=921378&view=rev + http://svn.apache.org/viewvc?rev=921526&view=rev + http://svn.apache.org/viewvc?rev=922407&view=rev + http://svn.apache.org/viewvc?rev=923418&view=rev + http://svn.apache.org/viewvc?rev=923429&view=rev + http://svn.apache.org/viewvc?rev=925986&view=rev + http://svn.apache.org/viewvc?rev=928881&view=rev + http://svn.apache.org/viewvc?rev=933341&view=rev + http://svn.apache.org/viewvc?rev=933547&view=rev + http://svn.apache.org/viewvc?rev=935339&view=rev +2.2.x patch: http://people.apache.org/~sf/mod_reqtimeout_up_to_r935339.diff +sf: It would be nice if someone could review this specifically WRT Windows +compatibility. ++1: sf + PATCHES/ISSUES THAT ARE STALLED * core: Support wildcards in both the directory and file components of
Re: Reducing number of mod_lua hook directives
The hook runner itself should just be in lua. Instead of scripts, you write lua modules. If a lua module has a function with the correct names (ie, same as hooks) it uses that: Ie in my module foo function fixups( r ) Would get called at fixups, etc. No need for a state per file, etc. Just have one state per thread. -- Brian Akins
Re: Reducing number of mod_lua hook directives
On Tue, May 11, 2010 at 08:47, Dan Poirier wrote:
> On 2010-05-11 at 08:52, Dan Poirier wrote:
>
>> On 2010-05-10 at 16:03, "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}
>>
>> So we'd have
>>
>> LuaHook AccessChecker funcname /path/to/script.lua
>>
>
>
> I just thought of a problem - right now, the funcname is optional
> (defaults to "handle"). I hate having optional arguments that don't
> come at the end. I'd just as soon make it a required argument, but if
> people would rather it stay optional, then I'd rather leave it at the
> end. What do folks prefer?
>
> Dan
>
I'd go for making it required, but is there a reason you have to
specify a function? Lua scripts usually start executing from the first
line in the file. It seems to me to make more sense to do that if a
function is not specified (or is "-" if it's a required argument).
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
On 2010-05-11 at 08:52, Dan Poirier wrote:
> On 2010-05-10 at 16:03, "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}
>
> So we'd have
>
> LuaHook AccessChecker funcname /path/to/script.lua
>
I just thought of a problem - right now, the funcname is optional
(defaults to "handle"). I hate having optional arguments that don't
come at the end. I'd just as soon make it a required argument, but if
people would rather it stay optional, then I'd rather leave it at the
end. What do folks prefer?
Dan
Re: Reducing number of mod_lua hook directives
On Tue, May 11, 2010 at 06:52, Dan Poirier wrote:
> On 2010-05-10 at 16:03, "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}
>
> So we'd have
>
> LuaHook AccessChecker funcname /path/to/script.lua
>
> and (unchanged)
>
>
>
> which makes the two forms more consistent too. Sounds fine to me.
>
> Dan
>
+1. Really looking forward to Lua as a web server language.
--
Sent from my toaster.
Re: Reducing number of mod_lua hook directives
On 2010-05-10 at 16:03, "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}
So we'd have
LuaHook AccessChecker funcname /path/to/script.lua
and (unchanged)
which makes the two forms more consistent too. Sounds fine to me.
Dan
