wer gibt bei einer website den header zurück? Server oder Browse

Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Forum>Netzwerke>wer gibt bei einer website den header zurück? Server oder Browse

tomthecat27.02.0717:48

Weiss jemand wer den header einer anforderung an einen server zurüückgibt? das ist doch der Server oder?

Konkret: Ich habe hier bei einer Seite immer einen Fehler 400 Badrequest. Die Seite wird zwar korrekt angezeigt in den Browsern, aber der Header gibt den Fehler 400 zurück und zwar immer nur, wenn ankerlinks in der URL stehen.
Nun habe ich beim Provider (den nicht ich ausgesucht habe) nachgefragt und die Antwort erhalten, gemäss logfiles gäbe es kein Error 400. Ich habe das sowiet ich konnt egeprüft und das stimmt auch. Trotzdem erhalte ich diesen Fehler im Header.
Nun könnte mir das eigentlich egal sein, aber rufe ich die Seite mit einem Textbasierenden Browser auf (lynx) oder mit curl im Terminal bekomme ich auch den fehler 400 zurück. Das bedeutet, google und andere Suchmaschinen werden die seite ignorieren da fehlermeldung...

Ach ja, ich kann nichts dafür der Server läuft auf einem IIS 6.0.

hier mal ein Link:

und ein anderer beim gleichen Provider:

mit dem gleichen Fehler.

Woran liegts jetzt? Am Server am Link, am Browser an mir?

Kommentare

tomthecat27.02.0717:49

Ach so, wenn man die gleichen Links ohne ankerlink verwendet, dann gibst kein Fehler.

Jaguar127.02.0719:14

Bei mir gibt's nie Fehler und ich lande immer oben auf der Seite (falls das 'ne Rolle spielt)...

„Die Menschen sind nicht immer was sie scheinen, aber selten etwas besseres.“

tomthecat27.02.0719:16

nein, spielt keine rolle. Es geht um den header, im normalen Browser siehst Du den Fehler bzw. den header nicht.

Jaguar127.02.0719:17

Was ist denn dann ein Header der Webseite? Kenne nur den Header einer Email...

„Die Menschen sind nicht immer was sie scheinen, aber selten etwas besseres.“

smile27.02.0719:28

hmm, also ich versteh die Frage auch nicht, obwohl ich mir einbilde http leidlich verstanden zu haben.

Normaler Ablauf:

Browser sendet GET bar.html an foo.de (http://foo.de/bar.html)
Server sucht die "Datei" bar.html und sendet diese als Ergebnis der Anfrage zurück. Der Browser interpretiert dann das Ergebnis als HTML / was auch immer und zeigt das Ergebnis an.

In dem Ablauf gibt es (mindestens) zwei header:

1. der <head> Bereich in der html Datei
2. der Requestheader, der vom Server zusammen mit der html Datei als Ergebnis zurück sendet.

1. kommt aus einer Datei auf dem Server / wird per Skript erzeugt
2. wird vom http Server erzeugt und beinhaltet u.a. den Serverstatus

die Serverstatusse werden in verschiedene Kategorien eingeteilt:

2xx - OK
3xx - Warnung
4xx - Fehler

Normalerweise werden bei den 4xx Statussen aber nicht die html Seiten zurückgegeben ?!

„Deinen Mac kannst du lieben oder hassen - Dein PC wird Dir immer scheißegal sein.“

tomthecat27.02.0719:30

Wenn du eine Website anforderst zB mit dem Browser, wird erst eine Art kommunikation gestartet. Erst danach wird die seite geladen.

Im Safari kann man das mit der Erweiterung WebDevAdditions zB. anzeigen lassen.

Da steht dann im normalfall zB:
HTTP/1.1 200 OK
Date: Tue, 27 Feb 2007 17:30:32 GMT
Server: Apache/1.3.26 (Unix) PHP/4.3.1 FrontPage/4.0.4.3
X-Powered-By: PHP/4.3.1
Content-Type: text/html

smile27.02.0719:30

guck mal, bei Wikipedia ist der Ablauf ganz gut beschrieben:

„Deinen Mac kannst du lieben oder hassen - Dein PC wird Dir immer scheißegal sein.“

Rantanplan27.02.0719:31

Ich möchte mal folgendes behaupten:

Der Fehler 400 sagt, daß die URL "mißgestaltet" ist. Da der Webserver mit einem Anker in der URL sowieso nichts anfangen kann, vermute ich mal, daß der von einem Browser üblicherweise auch nicht mitgesendet wird. und siehe da, wenn ich mir ankucke was der OW macht, dann klappt das auch:

Link:

Ergibt:

GET /products/en/8/11/In-House+Bank+IHB.html HTTP/1.1
Accept: */*
Accept-Language: de, en;q=0.94, fr;q=0.88, nl;q=0.81, it;q=0.75, ja;q=0.69, es;q=0.62, da;q=0.56, fi;q=0.50, ko;q=0.44, nb;q=0.38, pt;q=0.31, sv;q=0.25, zh-hans;q=0.19, zh-hant;q=0.12
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/420+ (KHTML, like Gecko, Safari/420) OmniWeb/v607.17

Und die Antwort (wie sie OW darstellt):

2007-02-27 18:27:50 Rx <http://www.treconex.com/products/en/8/11/In-House+Bank+IHB.html#test>
2007-02-27 18:27:50 Rx Status: 200 no error
2007-02-27 18:27:50 Rx Headers:
{
Connection = close;
"Content-Type" = "text/html; charset=iso-8859-1";
Date = "Tue, 27 Feb 2007 17:27:50 GMT";
Server = "Microsoft-IIS/6.0";
"X-Powered-By" = "PHP/5.1.1, ASP.NET";
}

Ich interpretiere das so, daß OW beim GET die URL ohne den Anker schickt. Man könnte jetzt mal nachlesen, ob der Anker in der URL überhaupt erlaubt ist (in einem GET/POST).

„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“

tomthecat27.02.0719:32

smile

Das ist ja das Problem. Der header gibt einen Fehler (der kommt ja vom Server, oder?) die seite wird angezeigt, das logfile auf dem Server protokolliert keinen Fehler.

tomthecat27.02.0719:34

Rantaplan

Gemäss Provider sollte da gar kein Problem sein. Da ja kein Fehler protokolliert wird, ist ja keiner. Die haben mir einen Link geschickt mit der Angabe es wäre alles in Ordnung:

tomthecat27.02.0719:42

Könnte das hier das Problem sein?

smile27.02.0719:43

öhm, klar sind Anker erlaubt, warum auch nicht?

Wikipedia sagt:
Viele URI-Schemata wie http oder ftp besitzen einen hierarchischen Aufbau:
<Schema>://[<Benutzer>[:<Passwort>]@]<Server>[:<Port>]/[<Pfad>][?<Anfrage>][&<weitere Anfrage>][#<Fragment>]
<Server> gibt hierbei bei Schemata, die ein TCP- oder UDP-basiertes Protokoll verwenden, den Domainnamen oder die IP-Adresse des Servers an; <Port> den TCP-Port (optional und nur anzugeben, wenn vom Standardport des Protokolls abweichend). <Benutzername> und <Passwort> werden meistens nicht gebraucht, können aber z. B. beim Dienst FTP zur Authentisierung benutzt werden. Das bedeutendste Schema ist http für das Hypertext Transfer Protocol.
Hierarchische URIs können ferner relativ zu einem Basis-URI angegeben werden. Hierbei werden Schema, Server und Port sowie gegebenenfalls Teile des Pfades weggelassen.
An URIs kann, abgetrennt durch #, auch ein Fragmentbezeichner angehängt werden. Eine Kombination aus URI und Fragmentbezeichner wird als URI-Referenz bezeichnet.

„Deinen Mac kannst du lieben oder hassen - Dein PC wird Dir immer scheißegal sein.“

smile27.02.0719:46

öhm, vielleicht solltest du die + in der URL korrekt kodieren??

„Deinen Mac kannst du lieben oder hassen - Dein PC wird Dir immer scheißegal sein.“

Rantanplan27.02.0719:56

smile

öhm, klar sind Anker erlaubt, warum auch nicht?

Hm, ich glaube du hast meine Antwort nicht vollständig gelesen. Ich habe extra erwähnt, daß ich die Spec nicht nachgeschlagen habe, sondern nur aufgrund der Sinnhaftigkeit (es ergibt keinen Sinn den Anker mitzuschicken, der Server kann daraus in einem GET nämlich nichts ableiten) und dem was OW angeblich laut Logfile an den Server schickt (der zwickt nämlich den Anker ab).

„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“

smile27.02.0720:14

„Deinen Mac kannst du lieben oder hassen - Dein PC wird Dir immer scheißegal sein.“

Rantanplan27.02.0720:25

Aber du hast natürlich recht Nach Spezifikation darf der Anker hinten dran sein. Auch wenn der Webserver damit nichts anfangen kann. Also war mein Erklärungsversuch ein Schuß ins Klo Mich wundert nur, daß OW den Anker abschneidet.

„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“

tomthecat27.02.0720:35

smile

Die + sind schon das ergebniss einer codierung. Ausserdem, machts keinen Unterschied...

Rantaplan

Genau ab # wird vom Browser interpretiert. Darum sollte es erstrecht dem Server egal sein. Trotzdem gibt er mit Anker eien 400 und ohne Akner einen 200.

Der Provider ignoriertst einfach.

wer gibt bei einer website den header zurück? Server oder Browse

Kommentare

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.