*Important*: As deflate; waits for the response headers, you must handle the request before it (see below how to check whether the request is handled).
*Important*: As @deflate;@ waits for the response headers, you must handle the request before it (see below how to check whether the request is handled).
If the request is not handled, you will get a "500 - Internal error" and a message in the error.log.
<short>caches content on memcached servers</short>
<description>
<textile>
<textile><![CDATA[
@lookup@ tries to find data associated with the key, and returns it as http body with status 200 if it finds something.
@store@ stores a http body (generated by another backend) in memcached.
@ -14,7 +14,7 @@
The other way is to purge the keys in your dynamic backend; you can set the memcached content from your backend too, which probably is faster than @memcached.store@.
If the key is longer than 255 bytes or contains characters outside the range 0x21 - 0x7e we will use a hash of it instead (for now sha1, but that may change).
</textile>
]]></textile>
</description>
<actionname="memcached.lookup">
@ -41,7 +41,7 @@
</action>
<actionname="memcached.store">
<short>searches the content in a memcached database</short>
<short>stores the generated respone in a memcached database</short>
<short>track connection progress (state) via a unique identifier</short>
<description>
<textile>
<textile><![CDATA[
mod_progress lets you track connection progress (or rather state) using a lookup table in which connections are registered via a random unique identifier specified with the request.
It is most commonly used to implement progress bars for file uploads.
@ -13,7 +13,7 @@
A live demonstration of a progress bar implementation can be seen at http://demo.lighttpd.net/progress/
Check the sourcecode there for further insight.
</textile>
]]></textile>
</description>
@ -29,12 +29,12 @@
<parametername="methods"/>
<default><value>("POST")</value></default>
<example>
<config>
<config><![CDATA[
setup {
module_load "mod_progress";
progress.methods ("PUT", "POST");
}
</config>
]]></config>
</example>
</option>
@ -48,7 +48,7 @@
<short>(optional) output format, one of "legacy", "json" or "jsonp". Defaults to "json".</short>
<short>protects files with a time limited code</short>
<sectiontitle="Install">
<textile>
<textile><![CDATA[
By default distributions (and @make install@) should provide the necessary files; but you can always find them in the "contrib":http://git.lighttpd.net/lighttpd/lighttpd2.git/tree/contrib folder:
* @secdownload.lua@
* @secdownload__secdownload.lua@
That way you can modify them for your own needs if you have to (although it is recommended to change the names of the files and the actions, so you don't get conflicts).
</textile>
]]></textile>
</section>
<actionname="secdownload">
@ -31,19 +31,19 @@
</table>
</parameter>
<description>
<textile>
The @prefix@ is not used to build the filename; include it manually in the @document-root@ (works like @"alias":plugin_core.html#plugin_core__action_alias "/prefix" => "/docroot").
<textile><![CDATA[
The @prefix@ is not used to build the filename; include it manually in the @document-root@ (works like @alias "/prefix" => "/docroot"@, see "@alias@":plugin_core.html#plugin_core__action_alias).
secdownload doesn't actually handle the (valid) request, it just provides the mapping to a filename (and rejects invalid requests).