Re: Additional core functions for mod_lua
I write a mod_luaex[ https://github.com/zhaozg/mod_luaex ] to extends mod_lua, it support session, dbd, filter and other, so more flexible. It use apreq, lua-apr[ https://github.com/zhaozg/lua-apr ],and merge function from http://people.apache.org/~humbedooh/lua_ap/. 2012/8/6 Daniel Gruno rum...@cord.dk If no one objects, I'll start moving in some functions to the mod_lua core, starting with the ones that pertain to obtaining a static value from the request/server, as well as the flush and sendfile function, and making them part of the request_rec package. This includes the following (as they will appear when imported): r:flush() - Flushes the output buffer r:sendfile(filename) - Sends a file using sendfile if available r.port -the port in use by the request r.banner - the server banner r.options - the Options directive for the request r.allowoverrides - the AllowOverride directive for the request r.started - the time the server was (re)started r.basic_auth_pw - the basic auth password, if any was sent r.limit_req_body - The current request body limit (or 0 for none) r.server_built -The time the server was built r.is_initial_req - Whether this is the initial request or a subreq r.remaining - The remaining bytes in the request body r.some_auth_required - Whether some authorization is/was required r.server_name - The server name for the request r.auth_name - The realm used (if any) for authorization This leaves the following functions still in the apache2 package - If you'd rather see any of them moved to the request_rec package, do say so - : apache2.base64_encode - Encode a string in base64 apache2.base64_decode - Decode a base64 string apache2.md5 - Generate an MD5 hash apache2.sha1 - Generate a SHA-1 hash apache2.escape -URL-escape a string apache2.unescape - unescape an URL-encoded string apache2.mpm_query - Query the MPM for information apache2.expr - Evaluate an ap_expr string apache2.scoreboard_process -Query the process scoreboard apache2.scoreboard_worker - Query a worker scoreboard apache2.clock - Returns the current time in microseconds apache2.requestbody - Fetches (or saves) the request body apache2.dbopen -Opens up a database connection (supports both apr_dbd and mod_dbd) apache2.add_input_filter - Adds an input filter to the request apache2.module_info - Queries the server for info about a mod apache2.loaded_modules -Lists all the loaded modules apache2.runtime_dir_relative - Returns a path relative to runtime dir apache2.server_info - Returns information about the executable apache2.set_document_root - Sets the document root for a request apache2.add_version_component - Adds a version component apache2.os_escape_path -Escapes a path as a URL apache2.strcmp_match - Does a strcmp_match (the foo* kind) apache2.set_keepalive - Set the keepalive status for a request apache2.make_etag - Creates an entity tag apache2.send_interim_response - Sends an interim response (or does it?) apache2.custom_response - Sets a custom response for an error msg apache2.exists_config_define - Query whether a define was made apache2.state_query - Queries the server for state info apache2.stat - Stats a file and returns info as a table apache2.regex - Evaluates regular expressions apache2.sleep - Sleeps for N seconds (accepts floats) apache2.get_server_name_for_url Servername for URL purposes Full descriptions and examples are still available at http://people.apache.org/~humbedooh/lua_ap/ if you need more info. If anyone has any other requests for internal functions they'd like to use in mod_lua, just speak up, I'm always happy to include more functionality. With regards, Daniel.
Re: Additional core functions for mod_lua
On 08/06/2012 12:17 AM, Stefan Fritsch wrote: Nice work. If you talk about the existing apache2 library, you mean it is existing in mod_lua? Or is it an external file? I meant the apache2 table we already have in place for return codes. Either that or we create a new table/library to hold them. There is some overlap with the r table: These already exist: apache2.context_document_root apache2.context_prefix apache2.add_output_filter Scrapped These can be done wit r.subprocess_env: apache2.getenv apache2.setenv Also scrapped Wouldn't it make sense to add those new functions which are really related to the request (as opposed to just using the request pool) to the r table, too? Yes, I had planned to add some of the functions that only apply to requests to the existing r structure, so we could do things like r:flush() and use r.port etc. If there's (lazy) consensus, I can just add all the functions pertaining to the request to that structure. Some other random notes: apache2.requestbody: This should take a size limit as argument. Done apache2.get_server_name: The example and the synopsis don't agree if this should have an argument Fixed apache2.get_server_name_for_url: This is missing but would be very useful. Added With regards, Daniel.
Re: Additional core functions for mod_lua
If no one objects, I'll start moving in some functions to the mod_lua core, starting with the ones that pertain to obtaining a static value from the request/server, as well as the flush and sendfile function, and making them part of the request_rec package. This includes the following (as they will appear when imported): r:flush() - Flushes the output buffer r:sendfile(filename) - Sends a file using sendfile if available r.port -the port in use by the request r.banner - the server banner r.options - the Options directive for the request r.allowoverrides - the AllowOverride directive for the request r.started - the time the server was (re)started r.basic_auth_pw - the basic auth password, if any was sent r.limit_req_body - The current request body limit (or 0 for none) r.server_built -The time the server was built r.is_initial_req - Whether this is the initial request or a subreq r.remaining - The remaining bytes in the request body r.some_auth_required - Whether some authorization is/was required r.server_name - The server name for the request r.auth_name - The realm used (if any) for authorization This leaves the following functions still in the apache2 package - If you'd rather see any of them moved to the request_rec package, do say so - : apache2.base64_encode - Encode a string in base64 apache2.base64_decode - Decode a base64 string apache2.md5 - Generate an MD5 hash apache2.sha1 - Generate a SHA-1 hash apache2.escape -URL-escape a string apache2.unescape - unescape an URL-encoded string apache2.mpm_query - Query the MPM for information apache2.expr - Evaluate an ap_expr string apache2.scoreboard_process -Query the process scoreboard apache2.scoreboard_worker - Query a worker scoreboard apache2.clock - Returns the current time in microseconds apache2.requestbody - Fetches (or saves) the request body apache2.dbopen -Opens up a database connection (supports both apr_dbd and mod_dbd) apache2.add_input_filter - Adds an input filter to the request apache2.module_info - Queries the server for info about a mod apache2.loaded_modules -Lists all the loaded modules apache2.runtime_dir_relative - Returns a path relative to runtime dir apache2.server_info - Returns information about the executable apache2.set_document_root - Sets the document root for a request apache2.add_version_component - Adds a version component apache2.os_escape_path -Escapes a path as a URL apache2.strcmp_match - Does a strcmp_match (the foo* kind) apache2.set_keepalive - Set the keepalive status for a request apache2.make_etag - Creates an entity tag apache2.send_interim_response - Sends an interim response (or does it?) apache2.custom_response - Sets a custom response for an error msg apache2.exists_config_define - Query whether a define was made apache2.state_query - Queries the server for state info apache2.stat - Stats a file and returns info as a table apache2.regex - Evaluates regular expressions apache2.sleep - Sleeps for N seconds (accepts floats) apache2.get_server_name_for_url Servername for URL purposes Full descriptions and examples are still available at http://people.apache.org/~humbedooh/lua_ap/ if you need more info. If anyone has any other requests for internal functions they'd like to use in mod_lua, just speak up, I'm always happy to include more functionality. With regards, Daniel.
Re: Additional core functions for mod_lua
On 08/03/2012 04:51 PM, Igor Galić wrote: I cannot seem to be able to find this stuff… I have put together some of the scripts I use myself at http://httpd.apache.org/docs/trunk/developer/lua.html but it's far from done (and thus not linked to from any index page). Most of the scripts are there, but I have yet to add actual explanations to the various examples as well as add the map handler examples and some other things. This page also holds all the functions that I have proposed to import into mod_lua (unless someone objects to specific functions), so this should answer Eric's question about documenting the functions as well. I have chosen to add the functions to the existing apache2 library, since the name makes sense. If there are no objections, I'll consider it a lazy consensus :) With regards, Daniel.
Re: Additional core functions for mod_lua
On Sunday 05 August 2012, Daniel Gruno wrote: On 08/03/2012 04:51 PM, Igor Galić wrote: I cannot seem to be able to find this stuff… I have put together some of the scripts I use myself at http://httpd.apache.org/docs/trunk/developer/lua.html but it's far from done (and thus not linked to from any index page). Most of the scripts are there, but I have yet to add actual explanations to the various examples as well as add the map handler examples and some other things. This page also holds all the functions that I have proposed to import into mod_lua (unless someone objects to specific functions), so this should answer Eric's question about documenting the functions as well. I have chosen to add the functions to the existing apache2 library, since the name makes sense. If there are no objections, I'll consider it a lazy consensus :) Nice work. If you talk about the existing apache2 library, you mean it is existing in mod_lua? Or is it an external file? There is some overlap with the r table: These already exist: apache2.context_document_root apache2.context_prefix apache2.add_output_filter These can be done wit r.subprocess_env: apache2.getenv apache2.setenv (though subprocess_env could use an abbreviation). I may have missed some others. Wouldn't it make sense to add those new functions which are really related to the request (as opposed to just using the request pool) to the r table, too? Some other random notes: apache2.requestbody: This should take a size limit as argument. apache2.get_server_name: The example and the synopsis don't agree if this should have an argument apache2.get_server_name_for_url: This is missing but would be very useful. apache2.satisfies: This is obsolete, and should IMHO be removed. apache2.getenv/setenv: call them request environment variable in the docs, to distinguish from OS environment variables Cheers, Stefan
Re: Additional core functions for mod_lua
On 08/06/2012 12:17 AM, Stefan Fritsch wrote: On Sunday 05 August 2012, Daniel Gruno wrote: On 08/03/2012 04:51 PM, Igor Galić wrote: I cannot seem to be able to find this stuff… I have put together some of the scripts I use myself at http://httpd.apache.org/docs/trunk/developer/lua.html but it's far from done (and thus not linked to from any index page). Most of the scripts are there, but I have yet to add actual explanations to the various examples as well as add the map handler examples and some other things. This page also holds all the functions that I have proposed to import into mod_lua (unless someone objects to specific functions), so this should answer Eric's question about documenting the functions as well. I have chosen to add the functions to the existing apache2 library, since the name makes sense. If there are no objections, I'll consider it a lazy consensus :) Nice work. If you talk about the existing apache2 library, you mean it is existing in mod_lua? Or is it an external file? There is some overlap with the r table: These already exist: apache2.context_document_root apache2.context_prefix apache2.add_output_filter These can be done wit r.subprocess_env: apache2.getenv apache2.setenv (though subprocess_env could use an abbreviation). I may have missed some others. Wouldn't it make sense to add those new functions which are really related to the request (as opposed to just using the request pool) to the r table, too? Some other random notes: apache2.requestbody: This should take a size limit as argument. apache2.get_server_name: The example and the synopsis don't agree if this should have an argument apache2.get_server_name_for_url: This is missing but would be very useful. apache2.satisfies: This is obsolete, and should IMHO be removed. apache2.getenv/setenv: call them request environment variable in the docs, to distinguish from OS environment variables Cheers, Stefan Yes, you caught some thing that I should have mentioned. The redundant functions you mentioned have been scrapped, it is simply because I'm generating the source for the xml doc via xslt, and I haven't gotten around to change the original xml file just yet (I've been painting :3). I'll get some sleep and fix up the docs tomorrow, including some mislabelled return values and parameters. As stated, this is a work in progress. As for the requestbody, satisfies etc functions, it's been noted and I'll see to it that they get changed/removed/fixed before I start committing anything. With regards, Daniel.
Re: Additional core functions for mod_lua
On Thu, Aug 2, 2012 at 7:40 AM, Daniel Gruno rum...@cord.dk wrote: Hi dev@, I've gotten my paws all over mod_lua as of late, trying to find ways to expand the module to be more useful. In doing so, I have created a small library which binds several httpd core functions (and some from apr) to Lua, so as to both gain more control over httpd via mod_lua as well as gain access to some of the many useful components included in our server by default. The library, and its reference docs can be found at http://people.apache.org/~humbedooh/lua_ap/ If they're already written, I don't see any reason to not include them. As long as we document carefully so they don't inundate someone developing a basic generator/handler, I think the library would be great to add to mod_lua. Some basic APR bindings would be cool too. Those should probably remain without tight ties to mod_lua, as they're useful outside of httpd.
Re: Additional core functions for mod_lua
- Original Message - Hi dev@, I've gotten my paws all over mod_lua as of late, trying to find ways to expand the module to be more useful. In doing so, I have created a small library which binds several httpd core functions (and some from apr) to Lua, so as to both gain more control over httpd via mod_lua as well as gain access to some of the many useful components included in our server by default. The library, and its reference docs can be found at http://people.apache.org/~humbedooh/lua_ap/ and while it's easy to just compile it and thus use its functions, I was thinking maybe we should include some of them as core functions in mod_lua itself. Hi Daniel, thank you very much for your hard work and this one especially. Here are some thoughts of mine after a quick glance: Right now, is your library meant to be linked with mod_lua or does it work with LoadFile? If you were planning to integrate it into the httpd project, would you as above, or would it become part of mod_lua? (From what I gather, it wouldn't make mod_lua more bloated) Finally, I'd like to say that all the httpd stuff is probably fine, the APR stuff though is a) Not namespaced as apr, and might be misplaced. I'm probably not competent enough to comment on this one, though. Specifically, I am leaning towards functions such as the flush function (for flushing the output buffer) and possibly either the base64 encode/decode functions or the get_basic_auth_pw function, so mod_lua has access to both username and password in its auth hooks without having to reinvent the wheel. This would also make it easier to write example scripts for many of our hooks. Other functions might be useful to include as well, so if any of you have some free time to explore the reference document, please have a look at the possibilities, and if you spot something you think would be useful as a core function, please reply and let me know. For an example of what you _could_ do with mod_lua, I have used this library to recreate mod_status in Lua, at http://www.apaste.info/server-status/ Other possibilities like making a Lua version of mod_vhost_alias (which could be expanded upon and do complex logic) also exist, but they don't show very well since they run in the background I cannot seem to be able to find this stuff… With regards, Daniel. That's all from me, thank you again for your hard work, Daniel i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Additional core functions for mod_lua
On 08/03/2012 04:51 PM, Igor Galić wrote: Right now, is your library meant to be linked with mod_lua or does it work with LoadFile? It's a Lua library, so it doesn't involve httpd per se. It would be included by mod_lua (or rather, by Lua) by writing the following in your script: local ap = require aplua function handler(r) ap.somestuff(r) -- do some AP stuff here end If you were planning to integrate it into the httpd project, would you as above, or would it become part of mod_lua? (From what I gather, it wouldn't make mod_lua more bloated) The only bloat you'd get is the extra microsecond it will take to register the functions in Lua. All the functionality is yanked straight from httpd (which has already loaded apr, pcre etc itself), so there's no additional memory use by including them. The only concern, if you will, is that there will be more functions to document. Finally, I'd like to say that all the httpd stuff is probably fine, the APR stuff though is a) Not namespaced as apr, and might be misplaced. I'm probably not competent enough to comment on this one, though. Yes, we could create a global table, ap, for the ap stuff, and apr for the apr stuff, or just make a table for apr, and have the rest registered within the request_rec table. I cannot seem to be able to find this stuff… The other examples I mentioned will be available in the developer docs, as soon as I've finished making it somewhat organized. With regards, Daniel.
