<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>workbench @ haefelinger.it &#187; apache httpd</title>
	<atom:link href="http://workbench.haefelinger.it/archives/category/admin/apache-httpd/feed" rel="self" type="application/rss+xml" />
	<link>http://workbench.haefelinger.it</link>
	<description>Notes, thouhts and other stuff on software development</description>
	<lastBuildDate>Wed, 07 Apr 2010 07:02:31 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Plesk</title>
		<link>http://workbench.haefelinger.it/archives/156</link>
		<comments>http://workbench.haefelinger.it/archives/156#comments</comments>
		<pubDate>Fri, 12 Feb 2010 11:17:22 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[apache httpd]]></category>
		<category><![CDATA[plesk]]></category>
		<category><![CDATA[apache_httpd]]></category>

		<guid isPermaLink="false">http://workbench.haefelinger.it/?p=156</guid>
		<description><![CDATA[Plesk is kind of freaky creature. Working with it can be a frustrating experience. Not when working with the graphical web interface. Used in that way, it&#8217;s easy to create/modify/remove sub-domains and other important tasks. However, the guys from Paralles do not expect apache to server something else than static pages. How else can it [...]]]></description>
			<content:encoded><![CDATA[<p>Plesk is kind of freaky creature. Working with it can be a frustrating experience. Not when working with the graphical web interface. Used in that way, it&#8217;s easy to create/modify/remove sub-domains and other important tasks. However, the guys from Paralles do not expect apache to server something else than static pages. How else can it be explained, that touching a vhost.conf file is something that is described in appendix A, A<em>dvanced Features</em>, in the Plesk manual?</p>
<p>So just assume that you have create a new subdomain and you want to make your CSS files available via <code>/css</code> instead of going via some hardwired domain URL. So all you want to have is an alias like</p>
<pre>
Alias /css "/path/to/my/css/folder"
</pre>
<p>Ok, but where to enter? When you look at the folder structure and files created by Plesk it is by no means clear what to do. But hey, what are manuals good for anyway? What you discover is that Plesk created a folder like</p>
<pre>
  /path/to/<strong>domain</strong>/subdomains/<strong>subdomain</strong>/conf
</pre>
<p>for your <em>subdomain</em>. The folder is empty. <strong>It would be really great if Plesk would in addition create a README file in that folder.</strong> That file would then state something like this:<br />
<i><br />
To configure your subdomain, add herein a file name vhost.conf. Put any Apache configurations in this file you like but be aware that this file is being included in a virtual host definition.</p>
<p>Once you have have added vhost.conf, please reconfigure this subdomain so that your file is taken into account. You do this by</p>
<pre>
 $ /usr/local/psa/admin/sbin/websrvmng --reconfigure-all
</pre>
<p>You need to do this only once, because this command does nothing more than insert a Include statement in /path/to/<strong>domain</strong>/conf/http.include. But refrain from do it manually because websrvmng will rewrite that file from scratch on the next run.</p>
<p>Oh, and btw notice that regardless of what our manual says you can only have a vhost.conf in a subdomain&#8217;s conf folder. Any vhost_ssl.conf therein is not taken into account.
</pre>
<p>Good luck and have a nice day.<br />
</i><br />
Unfortunately, that README file is missing.  Unfortunately.</p>
]]></content:encoded>
			<wfw:commentRss>http://workbench.haefelinger.it/archives/156/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mod_autoindex</title>
		<link>http://workbench.haefelinger.it/archives/13</link>
		<comments>http://workbench.haefelinger.it/archives/13#comments</comments>
		<pubDate>Sun, 13 Sep 2009 13:29:03 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[admin]]></category>
		<category><![CDATA[apache httpd]]></category>
		<category><![CDATA[apache_httpd]]></category>

		<guid isPermaLink="false">http://workbench.haefelinger.it/?p=13</guid>
		<description><![CDATA[Apache's webserver has got a reputation of being difficult to configure and <code>mod_autoindex</code> is actually a perfect example for this claim. I don't judge the software here as such, in my opinion, it's rather about the documentation. As a teaser, you might wonder what <code>mod_autoindex</code> generates by default? This is what get generated for a folder containg just a file and just a subfolder ..]]></description>
			<content:encoded><![CDATA[<p><code><a href="http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html">mod_autoindex</a></code> is a plugin for the the <a href="http://en.wikipedia.org/wiki/Apache_web_server">Apache web server</a>. The plugin is responsible for presenting the contents of a folder if folder browsing has been enabled and if a default file, traditionally <code>index.html</code>, is not available. </p>
<p>So far so good except that the default presentation generated by <code>mod_autoindex</code> is rather boring. We want to have it a bit more spicy. Therefore <code>mod_autoindex</code> has a lot of applicable options which are crying to be used. </p>
<p>Apache&#8217;s webserver has got a reputation of being difficult to configure and <code>mod_autoindex</code> is actually a perfect example for this claim. I don&#8217;t judge the software here as such, in my opinion, it&#8217;s rather about the documentation. As a teaser, you might wonder what <code>mod_autoindex</code> generates by default? This is what get generated for a folder containg just a file and just a subfolder:</p>
<pre lang="html">
&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
&lt;html>
 &lt;head>&lt;title>Index of /js&lt;/title>&lt;/head>
 &lt;body>
&lt;h1>Index of /js&lt;/h1>
&lt;ul>&lt;li>&lt;a href="/"> Parent Directory&lt;/a>&lt;/li>
&lt;li>&lt;a href="file"> file&lt;/a>&lt;/li>
&lt;li>&lt;a href="folder"> folder&lt;/a>&lt;/li>
&lt;/ul>
&lt;/body>
&lt;/html>
</html>
</pre>
<p>Let&#8217;s go one step further and take how to apply <a href="http://httpd.apache.org/docs/2.2/mod/mod_autoindex.html#indexoptions">index options</a> as an example. Index options can be used on a <em>server config level</em> or within a <em>directory tag</em>. In other words, you may have an <em>httpd.conf</em> file looking partially like</p>
<pre lang="apache">
IndexOptions XHTML
IndexOptions HTMLTable
&lt;directory />
 IndexOptions HTMLTable
&lt;/directory>
</pre>
<p>The overall question is: <em>what do we get by this?</em>. Obviously we try to enable XHTML and we try to enable the generation of a table instead of the unordered list (<code>&lt;ul></code>). But that&#8217;s not what we get. What we get is the html table rendered in plain HTML 3.2. How does this come?</p>
<p>It appears, and the documentation really needs to be more explicit on this, that index options are handled quite differently if they are encountered within a directory tag (<code>&lt;directory /></code>) or on the top level. When processing the configuration, Apache first calculates the value on the server config level. This is simply done by accumulating all index options into a list. For example, if there is <code>IndexOptions X</code> and somewhere later a <code>IndexOptions Y</code>, then we end up in a list like <code>{X, Y}.</code>. This is probably what you expect.</p>
<p>The server config value calculated is then applied to the root directory (<code>/</code>). If no directory tags are present, this is then the value applied.</p>
<p>If a directory tag for path <code>/foo/bar</code> is present, the value is calculated in two steps. In step one, the value is inherited from directory <code>/foo</code> which in turn will get its value from <code>/</code>.  In step two, index options found within the directory tag are applied <em>in an incremental fashion</em>.</p>
<p>Incremental index options are applied like this: if the options starts with a plus sign, the option&#8217;s value gets added to the list value. If it starts with a dash, the option&#8217;s value will be removed from the list. If neither plus not dash, the current list value is erased and the new list value will be the value of index option under investigation.</p>
<p>So, let&#8217;s have again a look at our configuration:</p>
<pre lang="apache">
IndexOptions XHTML
IndexOptions HTMLTable
&lt;directory />
 IndexOptions HTMLTable
&lt;/directory>
</pre>
<p>The calculated index option valaue after having processed the server config level before digging into the directory tag is {XHTML, HTMLTable}. Then directory <code>/</code> is processed by inheriting {XHTML, HTMLTable} followed by applying incremental rules. Therefore the final value is cleared and replaced by {HTMLTable}.</p>
<p>Notice on the other hand that incremental options on top level do not work at all:</p>
<pre lang="apache">
IndexOptions +XHTML
IndexOptions +HTMLTable
</pre>
<p>This has just no effect. Incremental options on top level are silently ignored.</p>
<p>In summary it&#8217;s mainly Apache&#8217;s documentation doing a bad job here:</p>
<ul>
<li>The documentation does not state what we have to expect if no options are applied</li>
<li>It is not clear at all how options are processed. Lots of other weired behaviours could have been implemented.</li>
<li>It is rather bad to use the same identifier (IndexOptions) for a different behaviour. If so this should be clearly documented</li>
</ul>
<p>I like to dwell in a bit on the last point. From a legacy point of view, older version of Apache supported non-incremental index options. Starting with Apache 1.3, incremental index options were added. So suddenly we can have index options that start with a plus character, or a dash or with extra character. Then someone decided that the absence of a character means <em>erase</em>. That conflicts of course with the legacy meaning where the absence of a character means actually <code>+</code>. </p>
<p>It would have been much better to define the <em>absence</em> of a character as <em>use the default</em> character and to use a third character for replacing. Such a character could have been <code>=</code>. Then we would end up in those rules, regardless whether on a server config level or within a directory:</p>
<ul>
<li>If an index options starts with <code>+</code> then it&#8217;s value is added.</li>
<li>If an index options starts with <code>-</code> then it&#8217;s value is removed.</li>
<li>If an index options starts with <code>=</code> then it&#8217;s value replaces the calculated value so far</li>
<li>Otherwise: treat the option as if the value starts with <code>+</code>.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://workbench.haefelinger.it/archives/13/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
