nicht angemeldet
MSIE 5.5 verstümmelt Location-Header?
Hi,
folgender User-Agent ist unangenehm ;-) aufgefallen:
Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; QXW0333p)
Ein Request von diesem wurde vom Server mit
Location: /direct/?url=http://bla/click.asp%3Fref=46139%3Dsite=746%3Dtype=text&unique=119902&type=1
beantwortet; also mit den Parametern 'url', 'unique' und 'type', wobei der Wert von 'url' eine URL (wer hätte das gedacht? *g*) beinhaltet, welche ihrerseits kodierte Parameter enthält - unter anderem 'type'.
Eigentlich nichts schlimmes, und aus meiner Sicht technisch vollkommen in Ordnung (obgleich die '=' auch hätten kodiert werden sollen). Man unterbreche mich bitte, wenn ich falsch liege.
Der nun folgende Request des o.g. Client sieht aber leider etwas anders aus:
GET /direct/?url=http://bla/click.asp%3Fref=46139&site=746&type=text&unique=119902&type=1 HTTP/1.0
Neben dem HTTP/1.0 (für IE typisch wäre eigentlich 1.1) fällt vor allem auf, daß die &-Zeichen innerhalb des url-Parameters dekodiert wurden, was zu unschönen Ergebnissen führt - insbesondere weil nun 'type' doppelt vorkommt.
Ist jemandem dieses Verhalten bekannt? Bug im IE? Mangels Systemverhunzung^Wentsprechender Software ;-) kann ich es leider nicht testen...
Cheatah
P.S.: Der REMOTE_HOST ist übrigens ein *.dip.t-dialin.net, falls das relevant sein könnte.
-
Hallo Cheatah,
zu Deinem eigentlichen Problem kann ich leider nicht viel (besser gesagt: gar nichts) beitragen.
Nur das folgende:
Neben dem HTTP/1.0 (für IE typisch wäre eigentlich 1.1)
Die einzigen, die sich in meinen Logfiles konsequent mit HTTP/1.1 verewigen, sind Mozilla/NN6 und Opera. Bei den Produkten aus dem Hause Microsoft ist es ein wildes Durcheinander aus HTTP/1.0 und 1.1, unabhängig von der IE-Versionsnummer und dem Betriebssystem (soll uns das jetzt irgendetwas sagen? ;-)
Viele Grüße
Carsten -
Moin,
Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; QXW0333p)
Location: /direct/?url=http://bla/click.asp%3Fref=46139%3Dsite=746%3Dtype=text&unique=119902&type=1^^^ ^
GET /direct/?url=http://bla/click.asp%3Fref=46139&site=746&type=text&unique=119902&type=1 HTTP/1.0
hmm, kann ich zumindest lokal hier nicht bestaetigen.
muessen die markierten Zeichen nicht auch maskiert werden? vielleicht kommt er ja damit durcheinander.
(bei der Gelegenheit kann man natuerlich das = auch gleich maskieren...)Viele Gruesse,
n.d.p.
-
Hallo Cheatah,
folgender User-Agent ist unangenehm ;-) aufgefallen:
Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; QXW0333p)Nur ein einziger? ;-) Und weist Du wer das war (jemand aus der Firma?)
Ein Request von diesem wurde vom Server mit
Location: /direct/?url=http://bla/click.asp%3Fref=46139%3Dsite=746%3Dtype=text&unique=119902&type=1[...]
Der nun folgende Request des o.g. Client sieht aber leider etwas anders aus:
GET /direct/?url=http://bla/click.asp%3Fref=46139&site=746&type=text&unique=119902&type=1 HTTP/1.0Ich habe das ganze mit Apache 1.3.12 und NN4.72 20000502 sowie IE 5.50.4134.0600 versucht.
Da der Apache Redirects ohne Protokoll und Host intern auflöst habe ich den Redirect um "http://localhost" ergänzt.NN:
"GET /cgi-bin/test.cgi HTTP/1.0" 302 359
"GET /direct/?url=http://bla/click.asp%3Fref=46139%3Dsite=746%3Dtype=text&unique=119902&type=1 HTTP/1.0" 200 80IE:
"GET /cgi-bin/test.cgi HTTP/1.1" 302 371
"GET /direct/?url=http://bla/click.asp%3Fref=46139%3Dsite=746%3Dtype=text&unique=119902&type=1 HTTP/1.1" 200 92Neben dem HTTP/1.0 (für IE typisch wäre eigentlich 1.1) fällt vor allem auf, daß die &-Zeichen innerhalb des url-Parameters dekodiert wurden, was zu unschönen Ergebnissen führt - insbesondere weil nun 'type' doppelt vorkommt.
Ist jemandem dieses Verhalten bekannt? Bug im IE? Mangels Systemverhunzung^Wentsprechender Software ;-) kann ich es leider nicht testen...Leider konnte ich Dein Problem nicht nachvollziehen. Das mit der Systemverhunzung allerdings schon. Deswegen starte ich den IE5.5 nur zu "besonderen Anlässen" ;-). Den IE5.5 habe ich auch nur drauf, weil niedrigere Versionen ja ein riesiges Sicherheitsrisko sind (vielleicht bis auf gepatchte 5.0x-Versionen ;-).
P.S.: Der REMOTE_HOST ist übrigens ein *.dip.t-dialin.net, falls das relevant sein könnte.
Dazu weis ich allerdings auch nichts näheres. :-|
Ich hoffe auch ohne Lösung des Problems geholfen zu haben.
Gruß AlexBausW
-
Moin Cheatah!
Vermutlich liegt hierin nicht die Ursache des Problems, jedoch ist es so, dass laut RFC2068 im Location-Header nur absolute URIs ausgegeben werden duerfen. (Ich meine mich zu erinnern, wir hatten dieses Thema vor langer Zeit hier schon, und auch, dass Du selbst uns das mitgeteilt hattest.) Andererseits gibst Du die relative URL ja vermutlich lediglich an die CGI-Schnittstelle, von wo der Webserver diese ja noch komplettieren kann. - Macht er das?
So long ersma
-
Hi,
ich habe vorhin ausführliche Antworten geschrieben, die leider nicht angekommen sind... Timeouts, oder aber Fehler vom Server ("...möglicherweise Festplatte voll...", "...wird gerade etwas anderes bearbeitet..."). Und natürlich ist mir irgendwann zwischendurch der Browser abgeschmiert :-( Naja, dann eben mal die Quintessenz als gesammelte Werke :-)
dass laut RFC2068 im Location-Header nur absolute URIs ausgegeben werden duerfen.
Stimmt. Üblicherweise schreibt der Server das automagisch um, bzw. reicht die lokale Ressource ohne Roundtrip zum Client raus - leider nicht bei uns. Nun, schade. Wieder ein Bug in einem nur allzu komplexen System...
Andererseits gibst Du die relative URL ja vermutlich lediglich an die CGI-Schnittstelle, von wo der Webserver diese ja noch komplettieren kann. - Macht er das?
Wenn's mal so einfach wäre :-)
Nein, wir arbeiten hier mit eigenen Servermodulen, die teilweise ziemlich verrückte Sachen machen. Eigentlich kein schlechtes System, hat aber verdammt viele Macken. Die Weiterentwicklung (eigentlich: Neuentwicklung), auf die ich demnächst umstelle, hat sicher genauso viele... und zwar andere :-) CGI ist jedenfalls derzeit nicht im Spiel.
Alex:
Könntest Du bitte in Deinem IE mal HTTP/1.1 aus den erweiterten Internetoptionen wegklicken und Dein Script noch mal testen? Ich habe nämlich (da der Fehler sonst nicht aufgefallen ist) die Vermutung, daß das ganze konfigurationsabhängig ist...n.d.:
Ja, "/" müßte eigentlich kodiert werden (obwohl es laut RFC 1738 im Searchpart eigentlich "nur" reserved ist); allerdings habe ich noch keinen Client gesehen, der damit Probleme hatte - daß ausgerechnet der I(do)E(verything) daran scheitert, wäre doch sehr verwunderlich :-)Carsten:
Wie gesagt kann ich das hier nicht mit dem IE testen; aber der Server selbst scheint unabhängig von HTTP/1.0 oder 1.1 immer das gleiche (nämlich kodierte Daten) auszuliefern.Ich danke euch allen für die Mühe!
Cheatah
-
Moin,
ich habe vorhin ausführliche Antworten geschrieben, die leider nicht angekommen sind... Timeouts, oder aber Fehler vom Server ("...möglicherweise Festplatte voll...", "...wird gerade etwas anderes bearbeitet..."). Und natürlich ist mir irgendwann zwischendurch der Browser abgeschmiert :-( Naja, dann eben mal die Quintessenz als gesammelte Werke :-)
da war wohl der Rechner wieder /etwas/ ueberlastet... ;/
dass laut RFC2068 im Location-Header nur absolute URIs ausgegeben werden duerfen.
Stimmt. Üblicherweise schreibt der Server das automagisch um, bzw. reicht die lokale Ressource ohne Roundtrip zum Client raus - [...]hmm, ist mir nie aufgefallen, jetzt weiss ich auch, wo die ganzen Umgebungsvariablen mit den lustigen Namen herkommen, interessante Sache, das ;)
Könntest Du bitte in Deinem IE mal HTTP/1.1 aus den erweiterten Internetoptionen wegklicken und Dein Script noch mal testen? Ich habe nämlich (da der Fehler sonst nicht aufgefallen ist) die Vermutung, daß das ganze konfigurationsabhängig ist...
HTTP/1.1 weggeklickt und keine Veraenderung.
Viele Gruesse,
n.d.p.
-
Hi,
da war wohl der Rechner wieder /etwas/ ueberlastet... ;/
man Skalierung ;-)
(Schon gut, ich hör ja schon auf! ... :-)
HTTP/1.1 weggeklickt und keine Veraenderung.
Hm, ich werde es wohl nie erfahren. Danke euch beiden.
Chea "Weiß einer, wie ich an seine eMail-Adresse rankomme? *g*" tah
-
-
Hallo Cheatah,
Alex:
Könntest Du bitte in Deinem IE mal HTTP/1.1 aus den erweiterten Internetoptionen wegklicken und Dein Script noch mal testen? Ich habe nämlich (da der Fehler sonst nicht aufgefallen ist) die Vermutung, daß das ganze konfigurationsabhängig ist...Habe ich gemacht, aber keine Änderung festgestellt. Auch nach Ausschalten der UTF-8-Codierung des URL gab es keine Änderung.
Gruß Alex
-
-