How to: set up web sharing on your Mac

Once you have upgraded to Leopard, any sites you have running locally won’t work, the problem is essentially that the config files have moved from /private/etc/httpd to /private/etc/apache2, BUT CARRY ON READING. You can’t just plonk your old config file into the new directory.

Here is what you need to do to set up the apache web server to serve your local site (and handle server side includes). You may need admin/root privileges for some/all of this, I can’t really remember and my notes are quite frankly illegible.
In the “/private/etc/apache2/other” directory create a file called “mywebsite.conf” and add the following text to it:

<Directory /Users/*/Sites>
AllowOverride FileInfo AuthConfig Limit
Options Includes
DirectoryIndex index.html index.cgi
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>

AddType text/html .shtml
AddHandler server-parsed .shtml

Then in the “/private/etc/apache2/users” directory create a file called “yourusername.conf” and add the following text to it (in the following example jojo is my username which you will need to replace):

<Directory "/Users/jojo/Sites/">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>

You will need to repeat this last step for each user that you would like to be able to host a site. When you have done this, restart websharing (under System Preferences -> Sharing) and then place your website in your “Sites” directory. You should now be able to browse to them in Safari (or whatever browser you use).

5 thoughts on “How to: set up web sharing on your Mac

  1. I thought my upgrade from Tiger had gone without a hitch, but you’re right, I had the web sharing problem I think you are describing. Official solution is here and worked for me. Not a very Appley fix though for all those iWeb users! Do you think they might have addressed it in a subsequent update?

  2. This is the same as the second part of the process that I describe, but if you want to use server side includes, or something similar, then you have to do the first part too.

    None of this is very “Appley”, but then again it is apache and not OS X that has the problem. Is it reasonable to expect Apple to provide software to manage the upgrade of all third party apps? To be honest, if you are using the local web server, it is reasonable to assume a degree of technical knowledge. Hmm, I’m on the fence on this one – I see your point, but it wasn’t that big of a problem to me once I worked out that the *.conf files needed moving/changing.

  3. Apple are including Apache and using it to support OS X’s personal web sharing, so of course it is down to them to ensure that Apache is correctly configured.

    I’m not a fan of Server Side Includes. Once you start wanting SSI, I think you’re better off using a server-side scripting language (e.g. PHP, Ruby). Simple includes are no more difficult, and you are not constrained to SSI’s very limited capabilities.

    Server side scripting isn’t just for dynamic application web sites. It can be very useful for DRY-ing up static web pages too.

  4. Yes, it usually is. What I’m saying is that server side scripting is far more powerful and facilities DRYness in ways that primitive SSI cannot, e.g. Lets say you had a Navigation menu common to all your pages, but on just one page you need an extra option. It would be clumsy to try and achieve this using SSI without duplication (one menu with the option, one without), but is a simple conditional expression in a script.

Leave a Reply

Your email address will not be published. Required fields are marked *