Kommentare zu: HTTP auf HTTPS-Port http://www.rackblogger.de/2011/12/15/http-auf-https-port/ We love to HOST you. :-) Sat, 25 May 2013 07:34:50 +0000 http://wordpress.org/?v=2.0.9 Von: Klaus Keppler http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-38073 Mon, 19 Dec 2011 12:00:36 +0000 http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-38073 @StefanF: danke noch mal für den Tipp, die Fehlermeldungen möchten wir bei Gelegenheit noch mal grundsätzlich überarbeiten (sowohl in die Sprache des Surfers übersetzen, als auch in "non-geek" :) Der Vergleich mit Facebook müsste aber eher so aussehen: http://facebook.com:443/ (HTTP-Zugriff auf einen HTTPS-Port). Ist nur dann ein häufigeres Problem, wenn die Dienste auf Nicht-Standard-Ports laufen (in unserem Fall eben 8443 statt 443). Es geht hier nicht darum ob man auf den falschen Port zugreift, sondern mit dem falschen Protokoll auf den richtigen Port. :) Praktisch kein Webserver und auch kein Browser gibt in diesem Fall eine Fehlermeldung aus, der Benutzer sieht einfach nur, dass es irgendwie "nicht funktioniert". Und um aus dem Nähkästchen zu plaudern: nachdem eine Praktikantin bei uns LiveConfig auf einer virtuellen Maschine frisch installiert hat und öffnen wollte, ist auch ihr genau das passiert. Und aus diesem Grund ist LiveConfig nun noch ein kleines Stück benutzerfreundlicher geworden. Wieder eine Supportanfrage weniger, die zu beantworten sein würde. @StefanF: danke noch mal für den Tipp, die Fehlermeldungen möchten wir bei Gelegenheit noch mal grundsätzlich überarbeiten (sowohl in die Sprache des Surfers übersetzen, als auch in “non-geek” :)
Der Vergleich mit Facebook müsste aber eher so aussehen: http://facebook.com:443/ (HTTP-Zugriff auf einen HTTPS-Port). Ist nur dann ein häufigeres Problem, wenn die Dienste auf Nicht-Standard-Ports laufen (in unserem Fall eben 8443 statt 443).

Es geht hier nicht darum ob man auf den falschen Port zugreift, sondern mit dem falschen Protokoll auf den richtigen Port. :)
Praktisch kein Webserver und auch kein Browser gibt in diesem Fall eine Fehlermeldung aus, der Benutzer sieht einfach nur, dass es irgendwie “nicht funktioniert”. Und um aus dem Nähkästchen zu plaudern: nachdem eine Praktikantin bei uns LiveConfig auf einer virtuellen Maschine frisch installiert hat und öffnen wollte, ist auch ihr genau das passiert. Und aus diesem Grund ist LiveConfig nun noch ein kleines Stück benutzerfreundlicher geworden. Wieder eine Supportanfrage weniger, die zu beantworten sein würde.

]]> Von: dermax http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-38054 Sun, 18 Dec 2011 21:56:02 +0000 http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-38054 Das ist aber sehr technisch gedacht. Ich kenne keine Seite, die bei einem HTTP-Request den Nutzer belehrt, dass die Applikation nur per SSL zur Verfügung steht. Entweder gibt's per HTTP gar keine Antwort, oder es wird stillschweigend auf die SSL-Variante geleitet. Ich kenne das Problem übrigens von Webseiten, die nicht konsequent entweder HTTP oder HTTPS verwenden und damit inkonsistente Verweise in meiner Browserhistory erzeugen. In diesem Fall wäre z. B. der falsche HTTP-Link in meiner History - die Gefahr besteht, dass ich ihn immer und immer wieder aufrufe. PS: Die gleichen Nutzer, die nicht zwischen HTTP und HTTPS unterscheiden, sind für die Firewall-Konfiguration zuständig? ;-) Das ist aber sehr technisch gedacht. Ich kenne keine Seite, die bei einem HTTP-Request den Nutzer belehrt, dass die Applikation nur per SSL zur Verfügung steht. Entweder gibt’s per HTTP gar keine Antwort, oder es wird stillschweigend auf die SSL-Variante geleitet.
Ich kenne das Problem übrigens von Webseiten, die nicht konsequent entweder HTTP oder HTTPS verwenden und damit inkonsistente Verweise in meiner Browserhistory erzeugen. In diesem Fall wäre z. B. der falsche HTTP-Link in meiner History - die Gefahr besteht, dass ich ihn immer und immer wieder aufrufe.

PS:
Die gleichen Nutzer, die nicht zwischen HTTP und HTTPS unterscheiden, sind für die Firewall-Konfiguration zuständig? ;-)

]]> Von: StefanF http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-38027 Sat, 17 Dec 2011 14:43:58 +0000 http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-38027 Richtet sich das an Endnutzer oder sind das technikaffinie Leute? Bitte auf eine nutzerfreundliche Fehlermeldung achten: Begriffe wie Bad Request, HTTP, HTTPS, SSL oder Port versteht nicht jeder. Wenn die Seite sowohl von Laien als auch Experten aufgerufen werden kann, sollte es m.E. sowohl eine laiengerechte Erklärung geben ("Sie haben versucht diese Seite unverschlüsselt aufzurufen. Klicken Sie hier für eine verschlüsselte Verbindung"), als auch - darunter - Geek-Speek (siehe oben). Generell finde ich es aber besser, keine Fehlermeldungen auszuwerfen wenn das System den Fehler selbst beheben kann. Wenn Du z.B. http://facebook.com eingibst, wirst Du automatisch auf https://facebook.com umgeleitet. Warum den Nutzer auf einen Fehler hinweisen? Richtet sich das an Endnutzer oder sind das technikaffinie Leute? Bitte auf eine nutzerfreundliche Fehlermeldung achten: Begriffe wie Bad Request, HTTP, HTTPS, SSL oder Port versteht nicht jeder. Wenn die Seite sowohl von Laien als auch Experten aufgerufen werden kann, sollte es m.E. sowohl eine laiengerechte Erklärung geben (”Sie haben versucht diese Seite unverschlüsselt aufzurufen. Klicken Sie hier für eine verschlüsselte Verbindung”), als auch - darunter - Geek-Speek (siehe oben).

Generell finde ich es aber besser, keine Fehlermeldungen auszuwerfen wenn das System den Fehler selbst beheben kann. Wenn Du z.B. http://facebook.com eingibst, wirst Du automatisch auf https://facebook.com umgeleitet. Warum den Nutzer auf einen Fehler hinweisen?

]]> Von: Klaus Keppler http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-37991 Fri, 16 Dec 2011 10:13:36 +0000 http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-37991 Haben wir uns ursprünglich auch überlegt, aber vorerst dagegen entschieden. Der Benutzer soll auf seinen Fehler hingewiesen werden; außerdem erleichtert die Fehlermeldung eine eventuelle Fehlersuche bei falschen Proxy-/Firewall-Konfigurationen. Eine Idee wäre, einen "universellen" Port einzurichten, den man sowohl per HTTP als auch per HTTPS ansprechen kann. Nennenswerte Performancenachteile dürfte es nicht geben (per HTTP Keep-Alive wird die Verbindung ja sogar eine Zeit lang für viele weitere Requests offen gehalten). Mal schauen... :-) Haben wir uns ursprünglich auch überlegt, aber vorerst dagegen entschieden.
Der Benutzer soll auf seinen Fehler hingewiesen werden; außerdem erleichtert die Fehlermeldung eine eventuelle Fehlersuche bei falschen Proxy-/Firewall-Konfigurationen.

Eine Idee wäre, einen “universellen” Port einzurichten, den man sowohl per HTTP als auch per HTTPS ansprechen kann. Nennenswerte Performancenachteile dürfte es nicht geben (per HTTP Keep-Alive wird die Verbindung ja sogar eine Zeit lang für viele weitere Requests offen gehalten).
Mal schauen… :-)

]]> Von: Claudius http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-37987 Fri, 16 Dec 2011 09:47:58 +0000 http://www.rackblogger.de/2011/12/15/http-auf-https-port/#comment-37987 Wäre es nicht Sinnvoller den Benutzer direkt auf https umzuleiten Anstand ihm eine Fehlermeldung zu präsentieren? Wäre es nicht Sinnvoller den Benutzer direkt auf https umzuleiten Anstand ihm eine Fehlermeldung zu präsentieren?

]]>