Apache AddHandler or AddType directive?

Simon Schoeters It took me a while to figure out the differences between the AddHandler and AddType directives in an Apache configuration. Both directives seem to define how the contents of a file with a given extension should be threatened but when do you need the first one and when the second? Turned out it isn't too hard... the AddType handler specifies how the client (think about a browser) has to deal with a particular data stream (e.g. download a binary or show an image or HTML page). The AddHandler on the other hand maps a handler to the file extension telling the server what to do with it. So if you are defining a Ruby on Rails or PHP content type you will need the AddHandler, telling the server it should parse the file. If you define a JavaScript or HTML file you will need the AddType one to tell the browser what content type to expect. <h3>Strict versus quirks mode</h3> Something slightly related is how browsers actually deal with the content type you set in your AddType directive. Gecko based browsers (like Firefox) follow the standard closely so they will handle a file according to the content type in your Apache configuration. This means your image will show up as text if you wrongly assigned the text/plain content type. Internet Explorer is more flexible and tries to guess the mime type for misconfigured web servers showing a wrongly defined images as, well, an image. <h3>More resources</h3> <ul> <li><a href="http://httpd.apache.org/docs/2.0/mod/mod_mime.html" title="Apache Module mod_mime documentation" class="ext">Apache's Module mod_mime documentation</a></li> <li><a href="http://developer.mozilla.org/en/docs/Properly_Configuring_Server_MIME_Types" title="Properly Configuring Server MIME Types at the Mozilla Developer Center" class="ext">Properly Configuring Server MIME Types</a></li> <li><a href="http://developer.mozilla.org/en/docs/Properly_Configuring_Server_MIME_Types" title="A sample .htaccess file at the Mozilla Developer Center" class="ext">A sample .htaccess file with common MIME types</a></li> </ul>

2007-09-05T15:10:08+02:00

addhandler-addtype-directives Apache AddHandler or AddType directive?

2007-10-07T01:59:19+02:00

Simon Schoeters After upgrading Ruby to 1.8.6 and Rails to 2.0.2 I ran intro problems with my installed gems. My application couldn't find any of the installed gems anymore! The <samp>gem list</samp> command returned the installed gems like you would expect and even the <samp>./script/console</samp> environment in my Rails application found the gems I needed but requiring a gem in one of my controllers like: <samp>require 'somegem'</samp> returned the following error: <samp>MissingSourceFile (no such file to load -- somegem)</samp> It took ages to find out what the problem was. My <a href="http://www.rubygems.org/read/chapter/3#page83" title="Installing RubyGems in a User Directory" class="ext">GEM_PATH</a> variable - this is where RubyGems looks for the installed gems - was set. I could find the gem from everywhere, except from within the controllers in my application. However, it did work fine when I ran the WEBrick server but when using my LightTPD production server everything went fubar. Turned out I forgot to tell LightTPD to use the new GEM_PATH, other than the default one. You can do this in the LightTPD configuration file. Maybe I changed the gem installation directory as I build RubyGems from source without knowing? Add the following to your LightTPD configuration file (change the paths where needed) and reload the server. <samp>fastcgi.server = (  ".fcgi" =>  (   "localhost" =>   (    "min-procs" => 1,    "max-procs" => 1,    "socket" => "<app>/tmp/sockets/fcgi.socket",    "bin-path" => "<app>/public/dispatch.fcgi",    "bin-environment" =>    (     "RAILS_ENV" => "production",     "GEM_PATH" => "/usr/local/lib/ruby/gems/1.8/"    )   )  ) )</samp> That's it, Suffix is now happily running the latest Ruby on Rails version.

2008-02-29T10:07:22+01:00

missing-gems-in-lighttpd Missing gems in LightTPD

2008-03-03T00:11:49+01:00

Simon Schoeters The System Preferences application on Mac is universal since Snow Leopard: it can run in 32-bit or 64-bit but not at the same time. That's why you have to restart the application when you want to open an older Preference Pane. Today I tried to upgrade the <a href="http://milkcarton.be/apps/lazypoken" title="A poken automounter" class="ext">LazyPoken</a> prefpane as it was still a 32-bit build and the next Mac OS X will probably no longer support the 32-bit System Preferences application. That turned out to be a little harder as expected. <h3>Build settings</h3> First of all you should change your project ARCH flags to tell the gcc compiler it should build for 64-bit. You can do this in Project → Edit Project Settings, choose the Build tab and look for the Architectures or ARCHS parameter. Choose the 64-bit or Universal mode (if you need to support Tiger). This is not enough however. If you try to build and install your application you'll notice it's still running in 32-bit, stubborn prefpane. The 64-bit System Preferences application also uses garbage collection and all 64-bit prefpanes need to support this as well. You can enable this in the same build panel under the Objective-C Garbage Collection or GCC_ENABLE_OBJC_GC parameter. Choose the Supported or Required option, again, depending on what you want to support. Clean and build your application again, check for warnings and try it out. Looking better now? <h3>64-bit gotchas</h3> <ul> <li>Sparkle: make sure to include the With Garbage Collection version of Sparkle, you just activated garbage collection remember?</li> <li>Older frameworks: make sure the frameworks your application depends on compile in 64-bit mode. The Developer Tools installed with Xcode include a tool to check your code for possible 64-bit incompatibilities. Read the <a href="http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Cocoa64BitGuide/ConvertingExistingApp/ConvertingExistingApp.html#//apple_ref/doc/uid/TP40004247-CH5-SW1" title="64-bit Trasition Guide for Cocoa" class="ext">Converting an Existing Application to 64-Bit</a> documentation.</li> </ul> Still running into problems? Read the <a href="http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/PreferencePanes/Articles/UpdatingPreferencePanesforSnowLeopardandBeyond.html" title="Updating Preference Panes for Snow Leopard and Beyond" class="ext">Updating Preference Panes for Snow Leopard and Beyond</a> article from Apple's Preference Pane Programming Guide.

2010-02-04T00:06:36+01:00

building-64bit-prefpane Building a 64-bit prefpane

2010-02-04T00:15:10+01:00