www.fabiankeil.de/blog-surrogat/2006/01/20/msn-search-filter.html
Über die Meldung zum Jubiläum des angeblich ersten Computer-Virus wurde ich auf das F-Secure-Blog aufmerksam, und dort auf den Hinweis, dass nun auch Microsofts Suchmaschine Abfragen blockiert.
   ![MSN-Search-Fehlermeldung mit Web-Developer-Extension überarbeitet: Semantik mangelhaft, Hinweis brauchbar [Ausschnitt der MSN-Fehlermeldung. Das folgende ist als Überschrift erster Ordnung deklarier:
    We are seeing an increased volume of traffic by some malware
    software. In order to protect our customers from damage from that malware, we are blocking your query.
    A few legitimate queries may get flagged, and for that we apologize. Please be assured that we are hard
    at work on this problem and hope to get it resolved even better as soon as possible.]](msn-403er-wenn-er-denn-kommt-392x413.png) Bei der Entscheidung ob eine Abfrage verweigert werden soll geht Microsoft
   nicht so
   dumm wie Google vor: mir wurde der Zugriff nicht komplett entzogen,
   das weiß ich zu schätzen.
 
   Bei der Entscheidung ob eine Abfrage verweigert werden soll geht Microsoft
   nicht so
   dumm wie Google vor: mir wurde der Zugriff nicht komplett entzogen,
   das weiß ich zu schätzen.
  
  
   Gefiltert wird der für mich irrelevante Suchbegriff phpbb
. Statt der Suchergebnisse liefert Microsoft
   eine Fehlermeldung aus und gibt im Gegensatz zu Google sogar zu, dass lediglich aufgrund
   des Suchbegriffs blockiert wurde; nicht wegen einer angeblichen Viren-Infektion im Netzwerk
   des Nutzers.
  
Bei der Quelltext-Semantik sieht es nicht ganz so positiv aus: wie im Screenshot-Ausschnitt zu sehen deklariert Microsoft die ganze Meldung als Überschriften.
Das verwundert ein wenig, die sonstigen Seiten liefert MSN Search nicht nur valide, sondern auch deutlich besser strukturiert als Google aus.
   Mit dem Filtern klappt es momentan noch nicht perfekt, sucht man mehrfach nach phpbb
   zeigt Firefox nur noch eine leere Seite an, die 403-Rückmeldung wird nicht weitergegeben.
  
Mein Firefox zeigt seit dem Update auf 1.5 keine Header mehr an, die Erweiterung ist angeblich zu alt und noch keine neue verfügbar. Ist natürlich Unsinn, aber nicht Thema dieser Seite.
   curl hilft weiter:
  
fk@TP51 ~ $curl -x 127.0.0.1:8118 -s -i 'http://search.msn.com/results.aspx?q=phpbb' |\ perl -n -e 'print if m/ / or exit' - HTTP/1.1 403 Forbidden Content-Type: text/html Content-Length: 0 Date: Fri, 20 Jan 2006 14:22:34 GMT Connection: close
   Microsoft meldet nur noch, dass der Aufruf verboten sei, lässt aber die Begründung weg.
   Wenn außer dem Header auch Inhalt mit ausgeliefert wird, enthält Content-Length die Seitengröße:
  
fk@TP51 ~ $curl -x 127.0.0.1:8118 -s -i 'http://search.msn.com/results.aspx?q=asp' |\ perl -n -e 'print if m/ / or exit' - HTTP/1.1 200 OK Content-Length: 11705 Content-Type: text/html; charset=utf-8 X-Powered-By: ASP.NET P3P: CP="NON UNI COM NAV STA LOC CURa DEVa PSAa PSDa OUR IND" Date: Fri, 20 Jan 2006 14:29:32 GMT Cache-Control: private Connection: close
Das Perl-Gehampel war notwendig, da die Akamai-Geister von MSN Search den Header nicht einzeln liefern wollten:
fk@TP51 ~ $curl -x 127.0.0.1:8118 --head 'http://search.msn.com/results.aspx?q=asp' HTTP/1.1 503 Service Unavailable Server: AkamaiGHost Mime-Version: 1.0 Content-Type: text/html Content-Length: 271 Date: Fri, 20 Jan 2006 14:23:21 GMT Connection: close
   Bei der curl-perl-Pipe ruft curl die komplette Seite wie
   ein Browser mit GET ab und gibt sie mitsamt
   Header an perl weiter. Header und Seitentext sind mit einer Leerzeile getrennt,
   perl gibt alles bis zur Leerzeile – also nur den Header – aus. 
  
Kleine Randnotiz: Wer keinen Filter-Proxy einsetzt, bekommt zusätzlich vier Cookies angeboten:
fk@TP51 ~ $curl -s -i 'http://search.msn.com/results.aspx?q=asp' |\ perl -n -e 'print if m/ / or exit' - HTTP/1.1 200 OK Content-Length: 11698 Content-Type: text/html; charset=utf-8 X-Powered-By: ASP.NET P3P: CP="NON UNI COM NAV STA LOC CURa DEVa PSAa PSDa OUR IND" Date: Fri, 20 Jan 2006 14:33:03 GMT Connection: keep-alive Set-Cookie: SRCHUID=V=1&GUID=5C2E33DB76544E1897C3705C00B43BF1; expires=Mon, 20-Jul-2015 23:59:59 GMT; path=/ Set-Cookie: SFORM=NOFORM; expires=Fri, 20-Jan-2006 15:03:03 GMT; path=/ Set-Cookie: SRCHUSR=AUTOREDIR=0&GEOVAR=-1&DOB=20060120; expires=Mon, 18-Jan-2016 14:33:03 GMT; path=/ Set-Cookie: SRCHSESS=GUID=C530B5828F8846CDBF703AA6BEFE6999&FLT=0&TS=1137767583; expires=Fri, 20-Jan-2006 14:53:03 GMT; path=/ Cache-Control: private
   Und wenn jetzt ein Google-Anhänger zurecht mosert, zehn Jahre haltbare Cookies seien böse, möchte ich
   ihm Googles Interpretation von Do no evil
 nicht vorenthalten:
  
fk@TP51 ~ $curl -s -i 'http://www.google.de/' |\ perl -n -e 'print if m/ / or exit' - HTTP/1.1 200 OK Cache-Control: private Content-Type: text/html Set-Cookie: PREF=ID=dfcf60d58d379dda:TM=1137768070:LM=1137768070:S=ckE7Ndct2F-IRnhg;\ expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.de Server: GWS/2.1 Transfer-Encoding: chunked Date: Fri, 20 Jan 2006 14:41:10 GMT