About a week or two ago, we decided to go for a Mac Mini Server (Snow Leopard Server) for our office environment. Since our switch to Macs about a year ago, this was the next logical step. Our goal was to use this server as a mail, chat, file, and print-server.

We started installing and configuring the Mac Mini Server, having little to no experience with the way Snow Leopard Server works. All our servers so far were either Microsoft of Linux based, so enough knowledge on server configuration in general, but no specific experience with the GUI provided by Mac OS X. Having read various articles on how easy to configure and how well integrated into the GUI all aspects of the Snow Leopard server are... we never saw wat was coming our way.

We found a few good articles and tutorials on setting op the server for first use, and we followed those closely. Everything seemed to work as advertised, but then the first little crack in the euforia came to light: All configuration panels were painstakingly slow. Server Preferences, Workgroup Manager and the Server Admin, all displayed the same behavior: endless spinners waiting on... what exactly? We figured out that all panels seemed to be waiting on some authentication process, based on Kerberos.

At this point, we started to suspect something was wrong with either some DNS settings (polling is a well know characteristic of invalid DNS settings), or with the authentication mechanism. So we tailed all logs we could find on the Mac Mini Server. We discovered that the server could not resolve the .local domain which we used at that time. Once we found that, we Googled for the .local domain and Mac OS X, and voila: There were a few blogs and even a Knowledge Base entry by Apple on using the .local domain. Seems .local is being used by Apple for Bonjour (previously Rendezvous).

So we changed our local domain from .local to something else, and most of the problems disappeared without a trace. Made us wonder though - considering all effort put in the GUI - why Apple did not include a simple this domain is reserved by Apple-warning when entering the .local domain.

It is tough to work through an unfamiliar situation. We found ourselves puzzled by a security warning when sending a visitor from a non-secure page on Eurobookings.com to a secure page. Strangely, this behavior was only found on IE6 and IE7. At first we thought of security settings of the browser, but there was no difference between those settings and the settings in other browsers (such as IE8).

Searching the web, we learned that using an iframe without the 'src' attribute set (or with src about:blank) on the secure page could be the cause. So we ditched the iframe on the secure page. No good.

That started the treadmill of plugins in our beloved browser Firefox to analyze exactly what happened (in terms of headers sent, files fetched, and so on). The search resulted in nothing particular at first, until we decided to get rid of all the extras on the page. Amongst the extras was a spinner to indicate that the secure page started loading.

What we did was set a spinner over the button after it was clicked to indicate loading and, as a handy bonus, to prevent people from submitting twice. That worked like a charm on every browser, except for IE6 and IE7. On those two browsers a page-load actions stops animated images. To overcome that, we had a javascript reset that spinner-image on IE6 and IE7 directly after clicking the button, which resulted in a working spinner on those browsers... and as we found out, in a security warning.

The spinner-image was not on a secure domain. And since the request to fetch that spinner-image from the server came in just a bit later than the secure-page-load event, the browser detected a request for 'non-secure content' while a secure page was loading. Hence the security warning. Go figure!