michi bloggt!

This screenshot shows the IE 5.5 accessing a Page, that responded with a status code of 400. Instead of displaying the according text from the response, it displays its own "friendly" error message, if the text is shorter than 513 characters. wtf?

Internet Explorer displays "friendly" errors as long as the content returned by the error handler is 512 bytes or fewer in length. The moment you hit 513, life is good again. [src]

This behaviour got fixed in IE 7.

Why is it, that a muli-threaded Java process (i.e. Helma) runs up to ten times slower, if I run Debian Etch with the latest Etch-Kernel 2.6.18-4-686 instead of using the old Sarge-Kernel 2.6.8-2-686-smp?

Somewhat related: Acer attackiert Microsoft.

Challenge: I want to extend certain DOM-elements with some JS-logic.

Sounds simple, but becomes tough if some other page components may change the DOM, e.g. by fetching additional elements via Ajax.

  $$(".task-delete").each(function(item) {
    item.onclick = ...
  });

So the above code needs to be called after the page has been loaded, but also needs to be called whenever the DOM changes (ie when a new element is inserted via Ajax for example).

Any Hints how to acchieve this?

Write-Up by Phil Hagelberg: http://technomancy.us/85/

-> http://www.paterva.com/wizard/

via kai raven, bzw via teemu per mail (thanks for the link!)

Getting more and more attention in the techosphere lately.

Specifically, two projects have really stood out as having a lot of potential.

JavaScript on Rails - ...

Helma - This web application framework is a long standing stalwart of server-side development with JavaScript (again, using Rhino). Surprisingly, it’s managed to fall through the cracks with just about every JavaScript developer that I know. I recently noticed it, and after some startup friends of mine revealed that they’re developing an application based on it, I became convinced that we’ll be hearing about this little framework in the upcoming months.

-> read the rest of John Resig's blog post

Also quite interesting: Bringing the Browser to the Server. Whereas this is not such big news, since you can acchieve quite the same with jala's HtmlDocument.scrape method.

Fünf Monate nach dem 1.5. Release wurde nun eine neue Version der beliebten JavaScript-Library released:
-> http://prototypejs.org/2007/5/1/prototype-1-5-1-released

Neben Geschwindigkeitsverbesserungen steht vor allem nun JSON en- und dekodierung als integraler Bestandteil der prototype zur Verfügung:
-> http://prototypejs.org/learn/json

Man ist also nicht mehr auf Douglas Crockford's Library angewiesen, um JSON-String (client- oder aber auch server-seitig) zu erstellen und sicher zu parsen.

Related: JavaScript Hijacking and how to prevent it

Solr is an open source enterprise search server based on the Lucene Java search library, with XML/HTTP and JSON APIs, hit highlighting, faceted search, caching, replication, and a web administration interface. It runs in a Java servlet container such as Tomcat.

-> http://lucene.apache.org/solr/ [features, wiki]
-> article at XML.com
-> Java Client
-> Faceted Searching With Apache Solr (pdf)

related:
-> http://www.seekport.biz/uk/index.html
-> http://fast.no/ (see scirus as demo)

Problemstellung: Die Daten eines Formulares, welches in eine ISO-8859-1 enkodierte Seite eingebettet ist, soll UTF-8 kodiert an eine (andere) URL gesendet werden.

Browser submitten in der Regel ihre Formulardaten stets in dem Encoding, in welchem die Seite gerendert wurde [quelle]. Mit dem Attribut accept-charset sollte man eigentlich das Encoding explizit angeben können, aber leider wird es vom IE nicht korrekt unterstützt. Der IE sendet nämlich das Formular nur dann in UTF-8, falls auch ein Sonderzeichen im Formular mit eingegeben wurde. Server-seitig kann man sich also nicht sicher sein, in welcher Kodierung die Daten übermittelt wurden.

Die IE-Entwickler haben aber seit dem IE 5 nun folgenden Workaround implementiert: Falls das Formular ein hidden-input-Feld namens _charset_ enthält, so wird dieses mit dem verwendeten Enkoding ausgefüllt an den Server mitgesendet.

<form action=".." method="POST" accept-charset="UTF-8">
  <input type="hidden" name="_charset_" value="" />
  ..
</form>

Nun muss man server-seitig dieses Hidden-Field abfragen, und entsprechend auf die mitgesandten Daten anwenden.

Das genaue IE-Verhalten lässt sich hier nachlesen: https://bugzilla.mozilla.org/show_bug.cgi?id=18643#c12

Der IE ist also noch immer für Überraschungen gut. Seufz.

Nachtrag: Die Servlet API stellt die Methode ServletRequest.setCharacterEncoding(String) zur Verfügung. Da man diese Methode aber aufrufen muss, bevor man den Request parsed, nützt einem das _charset_-Feld rein gar nichts, da man ja dieses auch nur aus den Request-Parametern auslesen kann.

Nachtrag 2: Wow, magic at work! Mein Beitrag erscheint automatisch unterhalb Sam Ruby's Artikel als Kommentar. Anscheinend nur durch den Referrer (oder Technorati?).

Nachtrag 3 (und die "Lösung" für die Problemstellung): Wie oben angemerkt wurde, sendet der IE nur in UTF-8 wenn ein entsprechendes Zeichen eingegeben wurde. Bzw wenn man client-seitig ein solches Zeichen einem Form-Feld einfügt. Auf diese Weise lässt sich der IE also doch noch dazu überreden, stets UTF-8 zu senden. Verrückt.

<form action=".." method="POST" accept-charset="UTF-8">
  <input type="hidden" name="dummyChar" value="&#9829;" />
  ..
</form>

Sehr interessant. Wenn man sich dieses PDF über 'RESTful Rails Development' durchliest, gewinnt man den Eindruck dass sich RoR gerade dorthin bewegt, wo sich Helma bereits seit Jahren aufhält.

Old school RoR: /stories/show/2

New school RoR (i.e. "RESTful" und "verschachtelt"): /projects/1/stories/2, /projects/1/stories/new