HTTPS erzwingen mit Apache und mod_rewrite
Keine Ahnung, wie oft ich das jetzt schon in PHP gelöst habe… hier ist die Variante, die bisher am einfachsten und wartungsfreundlichsten erscheint und daher irgendwo abgelegt gehört.
Voraussetzung sind zwei (virtuelle) Server mit dem selben Hostnamen, einer auf Port 80 und einer mit SSL auf Port 443. Will man ermöglichen, dass Nutzer z.B. durch manuelle Eingabe die Adresse http://… aufrufen und dann auf dem SSL-verschlüsselten Server landen, bietet sich ein Redirect von dem unverschlüsselten auf den verschlüsselten Server an.
Hier sind die zwei Zeilen für die Apache-Konfiguration, die z.B. in die .htaccess-Datei geschrieben werden können.
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://mein.server.de/$1 [R=301,L]
Möchte man nicht mit .htaccess arbeiten, kann man natürlich den Redirect auch ohne RewriteCond (und ohne mod_rewrite, dafür mit mod_alias und der Redirect-Direktive) direkt in die jeweilige Server-Konfiguration eintragen.
Suchtrends analysieren mit »Google Insights for Search«
Google nun hat (mal wieder*) ein Tool gelauncht, mit dem willige Nutzer nachvollziehen können, wie oft und wo nach bestimmten Begriffen gesucht wird/wurde. Es heißt Google Insights for Search.
Das bietet interessante Einblicke in Suchtrends und erlaubt nette Vergleichs-Spiele. Wie das obige Beispiel zeigt, wird nach iPods besonders häufig vor Weihnachten gesucht. Und das iPhone wird inzwischen häufiger gesucht als der iPod.
Seltsam, dass erst kürzlich mit Google Trends eine Appliaktion mit ganz ähnlicher Ausrichtung gelauncht wurde. Weiß inzwischen bei Google auch die eine Hand nicht mehr, was die andere tut? (Glaube ich nicht, denn im Bereich Synnergien und Code-Reuse wirkt Google eigentlich vorbildlich.)
Bei Google Blogoscoped wird spekuliert, welche Gründe die doppelte Implementierung haben könnte. Mysteriöses hat auch das deutsche GoogleWatchBlog bemerkt. Und hier ist die offizielle Ankündigung im Google AdWords Blog.
Gefunden via infosthetics.com.
Blogging Fatigue
Mensch, ich habe (hier) schon lange nichts mehr geschrieben. Ich habe Blogging Fatigue. Doch die 8 Tipps, die mir ProBlogger geben möchte (siehe Link), wollen nicht so recht greifen.
Hier bei sendung.de sind es, so glaube ich, sehr spezielle Dinge, die dem Senden im Wege stehen.
- Ich habe mich verändert. In den letzten drei Jahren habe ich Beschäftigungen entdeckt und wiederentdeckt, die meine Freizeit gut ausfüllen und mir viel Freude machen. Typischerweise könnte ich natürlich über meine Hobbies bloggen. Aber das kostet eben zusätzliche Zeit, was mich wieder von der Ausübung dieser Hobbies abhalten würde. Und wer abonniert den Feed eines Blogs, in dem es um User Interface Design und User Experience, Web Development, Typografie, Klettern, Musik und Gitarrespielen/-lernen geht? Das müssten schon ganz besonders eloquente (und viele) Beiträge sein, damit die jeweiligen Interessenten auf ihre Kosten kämen.
- Seit über zwei Jahren arbeite ich in Festanstellung. Das kostet nicht nur viel Zeit, sondern wir bloggen auch innerhalb der Firma, wodurch sich mein grundsätzliches Sendebedürfnis schon mal teilweise befriedigen lässt. Der Job macht es aber auch schwierig, über die Themen der Arbeit (User Experience, User Interface Design etc.) zu schreiben. Denn unsere Kunden schätzen es nicht besonders, wenn über ihre ungelegten Eier auf irgend einem privaten Blog diskutiert wird, und sei es nur, um zu zeigen, wie bestimte Details gelöst wurden.
- Vom Anspruch her war ich immer mehr ein Artikelschreiber als ein Blogger. Allerdings ist es mir nur mit wenigen Beiträgen gelungen, diesen Anspruch zu erfüllen. Zwei Beispiele: Redirecting your RSS traffic to Feedburner via mod_rewrite, Web Services, Output Formats and GZIP Compression. Diese Artikel sollten vor allem hilfreich sein für andere, die per Google zu diesem Thema recherchieren. Dieser Anspruch hat natürlich eine ganze Reihe Blog-typischer Kurzbeiträge verhindert und die Post-Frequenz minimiert, dafür den Aufwand maximiert. Eine vielleicht unsinnige Selbstbeschränkung.
- Die Sprachfrage. sendung.de ist zweifellos eine deutschsprachige Domain. Ich aber wollte immer gerne die große weite Welt ansprechen und habe daher immer versucht, auf Englisch zu schreiben. Kurz nach meinem achtmonatigen USA-Aufenthalt, der mittlerweile 7 Jahre zurück liegt, fiel mir das noch leicht. Inzwischen aber fällt es mir schwerer, mich auf Englisch differenziert auszudrücken. Dazu fehlt mir der permanente Kontakt mit Muttersprachlern.
Was bedeutet das für www.sendung.de?
Um ehrlich zu sein, weiß ich es auch noch nicht genau. Ziemlich sicher bedeutet es, dass hier nur noch deutschsprachiges erscheinen wird – wenn überhaupt. ProBlogger empfiehlt: Put the fun back into blogging. Mal sehen, vielleicht gelingt es mir, ein wenig Spaß am Bloggen selbst zu entdecken. Das könnte sehr wohl bedeuten, das der thematische Fokus hier noch unschärfer wird. Ich denke aber, es wird sich trotzdem immer wieder mal um User-Experience-Themen drehen.
Wie dem auch sei, es ist Zeit für einen Warmstart.
Discuss (1 comment)
1000 Pixel Design
Two fellow students of mine, Meike Eckstein and Robert Schwermer, started the project titled 1000 Pixel Design. They offer banner ads that help explain the value of design by simple statements like “Design affects emotionally”, “Design creates identity” or “Design conveys information easily”.
Above: “Design transportiert Informationen kinderleicht” by Martin Armbruster
Website owners are invited to display the banner ads on their website. In return, you will be mentioned and linked on the project website and a screenshot of your site will be shown on the Munich Design Parcour exhibition from February 28th untill March 9th, 2008.
Six different ad formats and statements have been produced by several contributors. The catch: All of them are german.
Here is the project website:
Redirecting your RSS traffic to Feedburner via mod_rewrite
So you host one or more blogs and discovered that serving the regular requests to your RSS feeds consumes a major share of your bandwidth? Good. Then you also heard of FeedBurner? Great. Then why not let FeedBurner answer the RSS requests?
Setting up a FeedBurner account is free and easy. But what if you alreday have tens of thousands of pleople subscribed to your RSS feeds?
If you host on the Apache Web Server, use mod_rewrite and have write access to your server configuration, here is a way how you can redirect the requests to your FeedBurner URL(s).
Complete apache configuration snipped:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} !(.*FeedBurner.*) [NC]
RewriteRule ^feed/.*$ http://feeds.feedburner.com/examplefdeed [R=301,L]
Explanation:
If you haven’t heard of Apache configuration, .htacces files and that stuff, you should start with the Apache documentation.
The code above does the following:
- Line 1 activates the mod_rewrite rewrite engine for this server or directory.
- Line 2 sets the base for URL parsing. Read all about this configuration directive in the mod_rewrite documentation.
- Line 3 sets a condition for URL rewriting. In this case, the rewriting shall only happen in case the HTTP_USER_AGENT contains the exact string FeedBurner. This is the case when FeedBurner comes to fetch your RSS feed. And is usually isn’t the case when other come looking for your RSS. The option [NC] makes this string comparison case insensitive.
- In line 4, the actual URL rewriting is configured. The first parameter describes which URL is currently used on your site in order to access the RSS feeds. As it’s written in the example, the pattern will match everything starting with /feed/, e.g. /feed/rss/, /feed/atom/. This is a convenience for wordpress users. The next parameter is the full URL to the according feed at FeedBurner’s. At the end, the options say that this should be a HTT 301 Redirect (301 means “moved permanently”) and the L makes this to be the last RewriteRule to be applied, just in case you have others in your configuration.
Now we redirect our feed requests to FeedBurner. The 1 Mio $ question is: When will Google FeedFetcher, Bloglines, Netvibes and all the other big RSS consumers plus the developers of RSS clients recognize? They continue requesting the original URL, thus issuing millions of unnecessary HTTP requests.
Discuss (1 comment)
Wedding on Wheels – Cologne (Germany) to Riva (Italy) by Bike
And here to something completely different:
My brother and his girlfriend just decided to get married in August next year. But it wouldn’t be my brother if there wasn’t anything extraordinary to it.
If you’re into biking (as in bicycle, not as in motorbike) and want to join them on their honeymoon bike tour from Cologne to Riva del Garda (or part of it), feel free to visit their (german) site.
Duplicate Contact Manager for Thunderbird: New Release for Thunderbird 2
Thunderbird 2 is in the makings and some early adopters have asked me for an updated version of Duplicate Contact Manager add-on.
Here it is. Please go to the add-on page
http://www.sendung.de/duplicatecontactsmanager-for-thunderbird/
in order to download. The addons page at addons.mozilla.org is currently awaiting the update, too.
I’m pleased to tell that the add-on has quite found it’s place amongst Thunderbird users. One thousand downloads per week aren’t bad. Especially those who synchronise their contacts with other tools such as PDA, phone, web services etc. obviously have tremendous trouble with duplicate contacts.
In the meantime, some skilled developers have started sending in code, wanting to help with thefurther development. I will try to make this a sourceforge project soon, so there will be a channel for gathering of requirements, source control etc.
Focus for the next version should be:
- Search between different address books
- Performance of search algorithm and scalability beyond 1000 contacts
- Localization
Discuss (17 comments)
Web Services, Output Formats and GZIP Compression
For the development at musik.sendung.de I have recently explored some of the texts on REST and RESTful web services. The topic is interesting for me both as a consumer as well as a (possible future) publisher of an API.
I guess one thing that should concern publishers as well as consumers of web services is the reasonable use of bandwidth.
Some web services offer the resource output in various flavors. They serve not only XML but also plain text (usually comma or tab seperated values), JSON data structures for immediate use within JavaScript or serialized PHP arrays or objects to serve the same purpose within PHP. Actually I love publishers who serve plain text, not only because it’s easy to parse in almost any language, but it’s also lightweight.
However, the chosen output format can have quite some influence on the amount of data to be transferred. I did a not-at-all-representative test with one kind of API of mine serving a list of 20 table items in four formats. The same information encoded in different data formats was quite different in size:
- XML: 15.5 KB
- PHP: 13.3 KB
- JSON: 10.2 KB
- CSV: 5.1 KB
When compressed using gzip, the output data becomes a lot smaller. The chart illustrates how compression affects the different data formats. The large bars indicate the original size, the small bars indicate size after compression. Absolute figures aren’t important here, so there is no actual scale.
Not bad, I think. Gzip compression saves between 73% and 85% of the bandwidth. The effect is largest in XML because the tags create a lot of redundancy. CSV, on the other hand, has only little redundancy, since there is almost no markup contained in the format.
When the effect of output compression is so big, why isn’t it supported more widely? Which one of the popular web service APIs support it? [See update below] None that I know of.
Is the bandwith usage for e.g. Amazon’s or Ebay’s API so marginal compared to everything else they serve? Probably. But that doesn’t have to be the case for every publisher.
One could argue that whoever provides an API should be able to afford the bandwidth. I’d respond: That’s a lame argument. When the whole web becomes a conglomerate of web service APIs, everybody who cares should be able to participate. And those who have a popular weblog know how bad it can get when increasing popularity means increasing bandwidth toll.
What about the additional CPU cost of compression? That could be an issue. Those who have their servers running on high CPU usage already would definitely have to test this.
On the other hand, since downloads can be handled faster, server threads can finish up faster and thus help to save server RAM. Theoretically.
For those who consume a web service, compression could be an issue when it’s not handled transparently by their client library. For example, PHP’s fopen() or file_get_contents() functions do not send the according “Accept-Encoding” headers when opening an HTTP URL.
For the AJAX-based web service clients running on the latest browsers it shouldn’t be an issue, though. Negotiation an decompression are handled transparently by the browsers.
Web services are usually not connected randomly, but only when a user/machine requests certain data (and that data is not cached on the consumer side). Especially when it comes to large datasets being transferred, compression could reduce the time used to complete an action based on the received data. Thus compression can help to improve application performance.
Updates
Which APIs support it? As soon as I find some, I will add them to this list.
- Google Base Data API: Yes
- Amazon E-Commerce Service: No
- Yahoo! Mail Web Services: Maybe (documentation doesn’t contain info, but one example shown contains the Content-encoding: gzip response header.
Some links:
- Speed Web delivery with HTTP compression – A look at the page-delivery effects of data compression in HTTP 1.1
- Webperformance.org compression resources
- mod_deflate – Compression module fpor Apache 2
- Squeezing SOAP – GZIP enabling Apache Axis
- Matt Chotin: Enabling gzip compression for [flex] data services
Discuss (4 comments)
Fort Minor feat. DIN Schablonierschrift
Hip-Hop artist Fort Minor makes extensive use of my DIN Schablonierschrift font on his website. That makes me happy!
Discuss (4 comments)
Social Bookmarks for the Mobile Web
The mobile web has been discussed by web designers and user experience experts for quite some time now. But does it actually exist?
Owning a web-capable PDA (with Opera and MSIE) and a mobile phone with an XHTML Browser, theoretically I have everything I need to spend hours and hours online, wherever I am.
Yet, what’s lacking is the awareness of good web content and services, prepared for mobile use. As far as portals, web directories and search engines are concerned, the mobile web feels like the “actual web” felt about 1995. Think Yahoo! web directory (not Dmoz.org), AltaVista (not Google) and private link pages like “my top 10 favorite web links”.
del.icio.us for mobile users
We have del.icio.us for social bookmarking and we have mobilicio.us, a great mobile HTML interface for del.icio.us. But we don’t have a way yet to find web pages that are usable on a PDA or mobile phone.
Where is the wisdom of the crowds when it comes to mobile web social bookmarking? There are some mobile URLs in del.icio.us already, but they are burried among “classical” WWW URLs, tagged with tags like pda, mobile, handheld or wap. But all of these tags are frequently used to tag URLs about PDAs, hendhelds, mobile phones, mobility and WAP.
Please, use the ‘formobile’ tag
I know, trying to make people use tags in a certain way is almost useless. I’ll try anyway.
If you have any interest in collecting URLs of web sites that are optimized for any type of mobile device (i.e. handheld, PDA, mobile phone), feel free to add these URLs to del.icio.us and tag them (amongst others) with the tag
I’ll go and track the development of the wisdom by counting the number of URLs there day by day 
. Currently it’s 55 formobile URLs.
Please leave comments here in case you have an opinion on this topic.
Discuss (2 comments)