Vielen Dank an Per Henrik Lausten, der mich mit seinem Tweet darauf aufmerksam gemacht hat:
Es gibt schon lange das Problem, dass der HTTP-Task des Domino-Servers auf einen Request, für den der Benutzer nicht berechtigt ist - meistens, weil er noch nicht oder nicht mehr angemeldet ist - mit einem Redirect auf die Login-Seite reagiert und - das ist das eigentliche Problem - dabei den Statuscode 200 zurück gibt, der dem Empfänger suggeriert: Alles in Ordnung.
Für den ursprünglichen Einsatzzweck ist das kein Problem: Mensch öffnet URL im Browser oder klickt auf einen Link, bekommt die Anmeldeseite, gibt seine Daten ein und wird auf die angeforderte Seite weitergeleitet.
Aber in einer Welt der Web Services und REST API Services, wenn ein "dummes" Programm versucht, einen entsprechenden Request abzusetzen, sieht es etwas anders aus. Das Programm bekommt ein 200 - alles okay - und gleichzeitig statt dem erwarteten Ergebnis irgendeine HTML-Seite, die er nicht einfach intepretieren kann. Natürlich kann der Programmierer, speziell wenn er mit Domino-Servern Erfahrung hat, darauf reagieren. Aber "die anderen" machen es alle (?) anders: In einem solchen Fall geben sie den HTTP Status 401 "not authorized" zurück. Dann kann der Aufrufer leichter erkennen, dass er sich noch anmelden muss.
Und mit dem Feature Pack 10 für IBM Domino 9.0.1 (und damit natürlich auch für Domino 10 aufwärts) gibt es jetzt eine notes.ini-Einstellung dafür:
DOMINO_FORCE401_WITH_HTML_LOGIN_PAGE=1
Ist diese Einstellung gesetzt, wird in dem geschilderten Fall auch ein Status 401 zurück gegeben.
Warum ist das nicht jetzt automatisch voreingestellt?
IBMs lange Tradition ist es, "Breaking Changes" nicht per Vorgabe auszuliefern. Immerhin mussten ja alle Service-Nutzer sich mit dem alten (Fehl-)Verhalten arrangieren und würden jetzt vielleicht nach der Umstellung einen Fehler produzieren. Die Entwickler sollen das vorbereiten können, bevor der Schalter umgelegt und das Verhalten des Servers geändert wird.
