phpbar.de logo

Mailinglisten-Archive

[php] Re: Anker in PHP setzen

[php] Re: Anker in PHP setzen

Martin Ramsch m.ramsch_(at)_computer.org
Tue, 7 Sep 1999 06:57:34 +0200


Werner Stürenburg schrieb am Freitag, den 3. September 1999:
> Martin Ramsch wrote:
> > | <scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
> > Leider widerspricht diese Form (#...?...) der in RFC 1808 definirten
> > Syntax von URLs:
[...]
> Strenggenommen sagt der Text nicht unbedingt etwas darüber aus, an
> welcher Stelle #<fragment> zu stehen hat; die Aussage bezieht sich
> ausdrücklich auf <params> und <query>.

Ich hätte vielleicht noch mehr zitieren sollen ...

In RFC 1808 ist die Reihenfolge aber eindeutig durch dieses Muster
festgelegt: <scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

Mehr noch, es heißt explizit:
| If the parse string contains a crosshatch "#" character, then the
| substring after the first (left-most) crosshatch "#" and up to the
| end of the parse string is the <fragment> identifier.

Siehe etwa <URL: http://rfc.fh-koeln.de/rfc/html_gz/rfc1808.html.gz >.


Aber wie Deine Tests zeigen, ist da wohl leider wiedermal ein
Unterschied zwischen dem formalen Standard und dem, was die Browser
daraus machen.

Insbesondere Netscape scheint da recht buggy zu sein, denn in meinen
Tests (allerdings mit alter V3.01) mit der Seite
<URL: http://www.forwiss.uni-passau.de/~ramsch/Test/php/x.php3&max=200 >
sieht es so aus:

- Wird die Seite am Anfang ohne Sprungziel aufgerufen, dann
  funktionieren Sprünge innerhalb der Seite problemlos;
  Das neue Sprungziel wird richtig am Ende des URLs eingebaut
  und die Seite wird beim Springen auch nicht neu geladen.

  Zumindest ein paar mal funktioniert es ...
  Manchmal (für mich nicht nachvollziehbar, wann) passiert nämlich
  auch das Gleiche, wie im zweiten Fall.

- Wird die Seite schon mit Sprungziel aufgerufen, dann macht Netscape
  bei Sprüngen innerhalb der Seite sofort Unsinn:  die GET-Parameter
  werden ein zweites mal hinten angehängt.
  Nun wird die Seite beim Springen auch jedesmal neu geladen.
  
Mein Fazit:  Netscape (zumindest die alte V3.01) ist hier fehlerhaft.


> > Das Problem mit dem (Nicht-)Caching müßtest Du vermeiden können, indem
> > Du im PHP-Skript "Last-Modified:" und evtl. "Expires:"-HTTP-Header
> > erzeugst.
> 
> Das sehe ich so nicht.

Hast recht, das bringt hier nichts.  Denn das Problem ist, daß
Netscape den URL falsch zusammenbaut und so jedesmal auf einen "neuen"
URL stößt, der natürlich auch neu geladen werden muß. :)


> Ich sehe zwei Probleme:
> 
> - einmal lädt die Seite neu, obwohl lediglich ein Anker innerhalb
> derselben Seite angesprungen werden soll. Das passiert bei Netscape
> ausschließlich mit GET-Variablen. 

Um diesen Netscape-Bug zu umschiffen, scheint die Angabe eines BASE-URL
zu genügen:
  <HEAD>
    ...
    <BASE HREF="<?php echo "$SCRIPT_URI?$QUERY_STRING"; ?>">
  </HEAD>
Dann baut Netscape die URLs wieder richtig zusammen (mit dem
Sprungziel ganz am Ende) und alles funktioniert bei mir dann, wie
gewünscht.

> - zweitens habe ich Situationen, in denen neue GET-Variablen an die
> alten drangehängt werden, sodaß die URL immer länger wird und
> natürlich furchtbar aussieht. 
[...]
> Das Phänomen, daß eine neue <query> an eine alte drangehängt wird,
> habe ich nur dadurch abstellen können, daß ich die URL der Datei mit
> übergebe, etwa in der Art:
> 
> 	<A HREF='http://pferdezeitung.com/savers/#a0?vorschau=" .
> $db->f("id") . "'>Vorschau</A>"

Sollte eigentlich auch relativ adressiert so gehen:
   HREF="?vorschau=4711#a0"

Nur kann das mein Netscape wieder nicht ... :(
Statt dem erwarteten
  http://www.forwiss.uni-passau.de/~ramsch/Test/php/x.php3?max=1000#500
baut der in meinem Fall
  http://www.forwiss.uni-passau.de/~ramsch/Test/php/?max=1000#500
zusammen.

Da hilft als Ersatzlösung wieder nur - wie Du geschrieben hast - ein
bißchen mehr vorzugeben:
   HREF="$SCRIPT_URL?vorschau=4711#a0"

> Hier würde es auch naheliegen, die Variablen $PATH_INFO oder
> $PHP_SELF zu verwenden; das geht nur auf Umwegen bzw. gar nicht, wie
> ich vor ein paar Tagen schon bemerkt habe. Beide Variablen sind bei
> Omni z. B. gar nicht gesetzt.

Wenn PHP_SELF fehlt, ginge das ja noch, weil das eine Erweiterung
durch PHP ist.  Aber PATH_INFO gehört zum CGI-Standard!  Gibt's das
wirklich nicht?  Oder evtl. nur dann, wenn der URL wirklich eine
Pfadinformation enthält?  Allerdings ist PATH_INFO, selbst wenn es
vorhanden ist, nicht der gewünschte URL des Skripts ...
Passende CGI-Variablen siehe meine Beispiele oben.
Stellt der Omni wenigstens SCRIPT_URI, SCRIPT_URL und QUERY_STRING zur
Verfügung?


> Aber im Zweifel dürfte der Fehler bei mir liegen und ich bitte um
> Aufklärung.

"Der Fehler sitzt vor dem Monitor" stimmt zwar nur zu oft, aber bei
Netscape und MS-IE ist das anders ... :)

Ciao,
  Martin
-- 
Martin Ramsch <m.ramsch_(at)_computer.org> <URL: http://ramsch.home.pages.de/ >
PGP: 0xE8EF4F75, 52 44 5E F3 B0 B1 38 26  E4 EC 80 58 7B 31 3A D7


php::bar PHP Wiki   -   Listenarchive