GlimmerBlocker
HTTP based ad blocker for Mac OS X
No hacks, no instability
Upgrade Safari whenever you like, no need to wait for an upgraded hack
GlimmerBlocker is no longer maintained and should no longer be used as web sites have migrated from using plain http to using https (i.e. encrypted) which prohibits modification by a proxy unless you resort to install custom SSL certiticates on the client.
You should use a browser extension instead.
It was made as a hobby project during 2007-2008 by Peter Speck. It features both a custom http server and http client and a Mac OS X control panel.
GlimmerBlocker did not only block requests but also allowed for adding custom css and javascript to the pages. It also allowed for modification of the page html before the browser receives the html, which made some modifications much easier than DOM based modifications.
Fixes QuickTime Streaming: an extraneous CRLF sequence was added when sending http headers when GlimmerBlocker in advanced knew that the connection could not use keep-alive. Reported by Dominic Wäsch and Matthias Wallner.
Fix problem with uploads to MobileMe/iDisk which takes a long time. The upload would cancel because GlimmerBlocker would timeout waiting for a reply from the server when it was still sending the file. Reported by Andreas Maks.
Fix of keep-alive bug: if server said keep-alive was valid for 45 seconds, GlimmerBlocker would reuse the connection only in the next 45 milliseconds. This would make some sites slower.
Don't use keep-alive on an http-server connection when the full request body has not been read. This can happen when an upload is denied by the server, and GlimmerBlocker would try interpret the file as an http request.
Installer script: Better diagnostics for non-working java installations and permission problems on e.g. /Library/PreferencePanes?. Thanks to Scott Collins for extensive testing.
Don't change content-type to text/html when a transform script has modified the content. This made it impossible to change javascripts without having Safari receive it as text/html, which it then would ignore and still use it as a script, but it was still wrong. If rule authors change the content-type, they must explicit set the content-type.
Allow request scripts to set the 'Accept-Encoding' header to one of: null, empty string or (exactly) 'gzip'. No other values are allowed as GlimmerBlocker must be able to decode the response.
Version 1.4.1 was released 2009-09-13.