Merge r1769899 from trunk:

Added a note in the mod_headers docs about Content-Type and setifempty

This note has been added as a follow up of a stack overflow post
(thanks to Michael Allan for the research):

http://stackoverflow.com/questions/29398123/apache-2-4-set-mime-type-of-file-without-extension

After a chat in #httpd-dev it seems that the issue boils down to how %{CONTENT_TYPE}
is evaluated in util_expr_eval.c (r->content_type) vs how setifempty is (only a check
of the response headers). This particular behavior might be a bug or feature,
but it is worth to alert our users.

Submitted by: elukey

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1770153 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/mod/mod_headers.xml b/docs/manual/mod/mod_headers.xml
index 99b38518d775d970dab1debbd92c81f96983ecff..a0c2eca929ae1466a05b579aee01b6f66810be2f 100644 (file)
--- a/docs/manual/mod/mod_headers.xml
+++ b/docs/manual/mod/mod_headers.xml
@@ -410,8 +410,17 @@ available in 2.4.10 and later</compatibility>
 
     <dt><code>setifempty</code></dt>
     <dd>The request header is set, but only if there is no previous header
-    with this name.<br />
-    Available in 2.4.7 and later.</dd>
+    with this name.
+    <note>
+    The Content-Type header is a special use case since there might be
+    the chance that its value have been determined but the header is not part
+    of the response when <code>setifempty</code> is evaluated.
+    It is safer to use <code>set</code> for this use case like in the
+    following example:
+    <highlight language="config">
+    Header set Content-Type "text/plain" "expr=-z %{CONTENT_TYPE}"
+    </highlight>
+    </note></dd>
 
     <dt><code>unset</code></dt>
     <dd>The response header of this name is removed, if it exists.