access control is still vulnerable, unless using OpenSSL >= 0.9.8l.
[Joe Orton, Ruediger Pluem, Hartmut Keil <Hartmut.Keil adnovum.ch>]
+ *) Allow fine control over the removal of Last-Modified and ETag headers
+ within the INCLUDES filter, making it possible to cache responses if
+ desired. Fix the default value of the SSIAccessEnable directive.
+ [Graham Leggett]
+
*) core: Fix potential memory leaks by making sure to not destroy
bucket brigades that have been created by earlier filters.
[Stefan Fritsch]
PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
[ start all new proposals below, under PATCHES PROPOSED. ]
- * mod_include: Allow fine control over the removal of Last-Modified and ETag headers
- within the INCLUDES filter, making it possible to cache responses if
- desired. Fix the default value of the SSIAccessEnable directive.
- 2.2.x patch: http://people.apache.org/~minfrin/mod_include_caching2-2.2.patch
- Trunk patch: http://svn.apache.org/viewvc?rev=905406&view=rev
- +1: minfrin, jim, rpluem
-
* mod_log_config: Add the R option to log the handler used within the
request.
Submitted by: Christian Folini <christian.folini netnea com>
</usage>
</directivesynopsis>
+<directivesynopsis>
+<name>SSIETag</name>
+<description>Controls whether ETags are generated by the server.</description>
+<syntax>SSIETag on|off</syntax>
+<default>SSIETag off</default>
+<contextlist><context>directory</context><context>.htaccess</context></contextlist>
+
+<usage>
+ <p>Under normal circumstances, a file filtered by <module>mod_include</module>
+ may contain elements that are either dynamically generated, or that may
+ have changed independently of the original file. As a result, by default
+ the server is asked not to generate an <code>ETag</code> header for the
+ response by adding <code>no-etag</code> to the request notes.</p>
+
+ <p>The <directive>SSIETag</directive> directive suppresses this
+ behaviour, and allows the server to generate an <code>ETag</code> header.
+ This can be used to enable caching of the output. Note that a backend server
+ or dynamic content generator may generate an ETag of its own, ignoring
+ <code>no-etag</code>, and this ETag will be passed by
+ <module>mod_include</module> regardless of the value of this setting.
+ <directive>SSIETag</directive> can take on the following values:</p>
+
+ <dl>
+
+ <dt><code>off</code></dt>
+ <dd><code>no-etag</code> will be added to the request notes, and the server
+ is asked not to generate an ETag. Where a server ignores the value of
+ <code>no-etag</code> and generates an ETag anyway, the ETag will be
+ respected.</dd>
+
+ <dt><code>on</code></dt>
+ <dd>Existing ETags will be respected, and ETags generated by the server will
+ be passed on in the response.</dd>
+
+ </dl>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSILastModified</name>
+<description>Controls whether <code>Last-Modified</code> headers are generated by the
+server.</description>
+<syntax>SSILastModified on|off</syntax>
+<default>SSILastModified off</default>
+<contextlist><context>directory</context><context>.htaccess</context></contextlist>
+
+<usage>
+ <p>Under normal circumstances, a file filtered by <module>mod_include</module>
+ may contain elements that are either dynamically generated, or that may
+ have changed independently of the original file. As a result, by default
+ the <code>Last-Modified</code> header is stripped from the response.</p>
+
+ <p>The <directive>SSILastModified</directive> directive overrides this
+ behaviour, and allows the <code>Last-Modified</code> header to be respected
+ if already present, or set if the header is not already present. This can
+ be used to enable caching of the output. <directive>SSILastModified</directive>
+ can take on the following values:</p>
+
+ <dl>
+
+ <dt><code>off</code></dt>
+ <dd>The <code>Last-Modified</code> header will be stripped from responses,
+ unless the <directive module="mod_include">XBitHack</directive> directive
+ is set to <code>full</code> as described below.</dd>
+
+ <dt><code>on</code></dt>
+ <dd>The <code>Last-Modified</code> header will be respected if already
+ present in a response, and added to the response if the response is a
+ file and the header is missing. The
+ <directive module="mod_include">SSILastModified</directive> directive
+ takes precedence over <directive module="mod_include">XBitHack</directive>.</dd>
+
+ </dl>
+
+</usage>
+</directivesynopsis>
+
<directivesynopsis>
<name>XBitHack</name>
<description>Parse SSI directives in files with the execute bit
group-execute bit is unset for every SSI script which might <code
>#include</code> a CGI or otherwise produces different output on
each hit (or could potentially change on subsequent requests).</p>
+
+ <p>The <directive module="mod_include">SSILastModified</directive>
+ directive takes precedence over the
+ <directive module="mod_include">XBitHack</directive> directive when
+ <directive module="mod_include">SSILastModified</directive> is set to
+ <code>on</code>.</p>
</note>
+
</dd>
</dl>
const char *default_time_fmt;
const char *undefined_echo;
xbithack_t xbithack;
- const int accessenable;
+ int accessenable;
+ int lastmodified;
+ int etag;
} include_dir_config;
typedef struct {
#define DEFAULT_ERROR_MSG "[an error occurred while processing this directive]"
#define DEFAULT_TIME_FORMAT "%A, %d-%b-%Y %H:%M:%S %Z"
#define DEFAULT_UNDEFINED_ECHO "(none)"
+#define DEFAULT_ACCESSENABLE 0
+#define DEFAULT_LASTMODIFIED 0
+#define DEFAULT_ETAG 0
#ifdef XBITHACK
#define DEFAULT_XBITHACK XBITHACK_FULL
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
- apr_table_setn(f->r->notes, "no-etag", "");
+ if (!conf->etag) {
+ apr_table_setn(f->r->notes, "no-etag", "");
+ }
return OK;
}
* a program which may change the Last-Modified header or make the
* content completely dynamic. Therefore, we can't support these
* headers.
- * Exception: XBitHack full means we *should* set the Last-Modified field.
+ *
+ * Exception: XBitHack full means we *should* set the
+ * Last-Modified field.
+ *
+ * SSILastModified on means we *should* set the Last-Modified field
+ * if not present, or respect an existing value if present.
*/
+ /* Must we respect the last modified header? By default, no */
+ if (conf->lastmodified) {
+
+ /* update the last modified if we have a valid time, and only if
+ * we don't already have a valid last modified.
+ */
+ if (r->finfo.valid & APR_FINFO_MTIME
+ && !apr_table_get(f->r->headers_out, "Last-Modified")) {
+ ap_update_mtime(r, r->finfo.mtime);
+ ap_set_last_modified(r);
+ }
+
+ }
+
/* Assure the platform supports Group protections */
- if ((conf->xbithack == XBITHACK_FULL)
+ else if (((conf->xbithack == XBITHACK_FULL)
&& (r->finfo.valid & APR_FINFO_GPROT)
- && (r->finfo.protection & APR_GEXECUTE)) {
+ && (r->finfo.protection & APR_GEXECUTE))) {
ap_update_mtime(r, r->finfo.mtime);
ap_set_last_modified(r);
}
result->default_time_fmt = DEFAULT_TIME_FORMAT;
result->undefined_echo = DEFAULT_UNDEFINED_ECHO;
result->xbithack = DEFAULT_XBITHACK;
+ result->accessenable = DEFAULT_ACCESSENABLE;
+ result->lastmodified = DEFAULT_LASTMODIFIED;
+ result->etag = DEFAULT_ETAG;
return result;
}
AP_INIT_FLAG("SSIAccessEnable", ap_set_flag_slot,
(void *)APR_OFFSETOF(include_dir_config, accessenable),
OR_LIMIT, "Whether testing access is enabled. Limited to 'on' or 'off'"),
+ AP_INIT_FLAG("SSILastModified", ap_set_flag_slot,
+ (void *)APR_OFFSETOF(include_dir_config, lastmodified),
+ OR_LIMIT, "Whether to set the last modified header or respect "
+ "an existing header. Limited to 'on' or 'off'"),
+ AP_INIT_FLAG("SSIEtag", ap_set_flag_slot,
+ (void *)APR_OFFSETOF(include_dir_config, etag),
+ OR_LIMIT, "Whether to allow the generation of ETags within the server. "
+ "Existing ETags will be preserved. Limited to 'on' or 'off'"),
{NULL}
};
projects / thirdparty / apache / httpd.git / commitdiff
