Link auf Anker macht Probleme

[zippex]

Hallo!
Ich habe eine Webseite geschrieben, bei der unter anderem Sprünge in langen php-Dokumenten mit Ankern geschehen sollen (über eine Subnavigation in einem Frame). Bei mir zu Hause auf einem Apache-Server lief das ohne Probleme, auch die Testversion auf meiner Domain bei 1&1 funktionierte.
Nur auf dem Server meines Auftraggebers funktionieren die Anker nicht (er hat definitiv eine 1:1-Kopie meiner Testversion bekommen und ich habe die ihm geschickte Version zum Test ebenfalls wieder bei mir auf dem Server installiert - da gingen die Anker auch wieder).

Konkret:
Kann es sein, dass eine spezielle Server-Konfiguration (in diesem Fall auch ein Apache) Sprünge zu Ankern unterbindet? Also dass Links auf z.B. http://www.irgendwas.de/index.php#anker1 nicht funktionieren?
Das php-Dokument gibt korrekt validierten HTML-Code aus, die Anker wurden korrekt gesetzt, ebenso die Links auf die Anker (wie gesagt, auf zwei Servern von mir hat es funktioniert).

Bin ratlos und für jede Hilfe dankbar!
mfG zippex

[Stefan Einspender]

Hallo,

was im PHP-Quelltext steht, interessiert hier niemand, einzig und
allein eine klitzekleine Frage mußt Du uns beantworten: URL?

Viele Grüße,
Stefan

[zippex]

URL?

Viele Grüße,
Stefan

Hallo!
Da das Projekt noch nicht offiziell ist darf ich die URL leider nicht angeben - auch nicht die URL für die Testversion. Aber ich kann die entsprechenden Auszüge aus den Quelltexten posten:

-----------
index.php
-----------
Hier wiederholt sich in einem HTML-Grundgerüst pro Nachricht folgende Tabelle, wobei der Anker <a name="0"> durch das php-Skript gesetzt wird.

<table border="0" width="735" cellpadding="2" cellspacing="0">
  <tr>
    <td colspan="2"><span class="datum">
 <a name="0"></a>27.03.2004</span>
    </td>
  </tr>
  <tr>
    <td colspan="2"><span class="titel">Test-Titel</span>
    </td>
  </tr>
  <tr>
 [...]
  </tr>
</table>

----------
submenu
----------
In einem Frame werden innerhalb eines div-Containers die entsprechenden Links auf die Anker gesetzt.

<div style="[...]">
<a href="./index.php#0" target="maincontent">Test-Titel</a>
</div>

Es tut mir leid, dass ich das nicht 100%ig beschreiben kann/darf. Die Quelltexte der funktionierenden und nicht-funktionierenden Version sind absolut identisch - daher kann der Fehler meiner Meinung nach nur am Server liegen (in diesem Fall läuft die nicht-funktionierende Version auf einem Uni-Server, wird also auf dem Weg zum Betrachter sicher mehrmals gecached - was allerdings auch nicht so recht die Ursache sein kann, andere gecachte Seiten mit Anker-Links funktionieren ja auch).
Viele Grüße,
zippex

[Ingo Turski]

Hi,

<a href="./index.php#0" target="maincontent">Test-Titel</a>

^ dies ist kein güligr Ankername.

freundliche Grüße
Ingo

[MudGuard]

Hi,

<a href="./index.php#0" target="maincontent">Test-Titel</a>
                        ^ dies ist kein güligr Ankername.

Doch, das ist ein gültiger Ankername.

Das name-Attribut des a-Elements ist (siehe http://www.w3.org/TR/html401/struct/links.html#adef-name-A) als CDATA deklariert.
CDATA ist (siehe http://www.w3.org/TR/html401/types.html#type-cdata) wie folgt definiert:

CDATA is a sequence of characters from the document character set and may include character entities. User agents should interpret attribute values as follows:

* Replace character entities with characters,
    * Ignore line feeds,
    * Replace each carriage return or tab with a single space.

User agents may ignore leading and trailing white space in CDATA attribute values (e.g., "   myval   " may be interpreted as "myval"). Authors should not declare attribute values with leading or trailing white space.

For some HTML 4 attributes with CDATA attribute values, the specification imposes further constraints on the set of legal values for the attribute that may not be expressed by the DTD.

Although the STYLE and SCRIPT elements use CDATA for their data model, for these elements, CDATA must be handled differently by user agents. Markup and entities must be treated as raw text and passed to the application as is. The first occurrence of the character sequence "</" (end-tag open delimiter) is treated as terminating the end of the element's content. In valid documents, this would be the end tag for the element.

Ich sehe da keine Einschränkung, die '0' nicht zulassen würde.

Und nein, der folgende Listenpunkt (ID and NAME tokens) hat _NICHTS_ mit CDATA zu tun.

cu,
Andreas

[Ingo Turski]

Hi,

Doch, das ist ein gültiger Ankername.

danke. Mal wieder was dazugelernt. Diese Möglichkeit habe ich vielleicht auch verdrängt, weil ich immer IDs als Anker verwende anstatt ein name-Attribut zu setzen.

Vielleicht liegt das Problem dann bei den erwähnten sehr langen Seiten i.V. mit den Tabellenkonstruktionen?

freundliche Grüße
Ingo

[MudGuard]

Hi,

Ich habe eine Webseite geschrieben, bei der unter anderem Sprünge in langen php-Dokumenten mit Ankern geschehen sollen (über eine Subnavigation in einem Frame). Bei mir zu Hause auf einem Apache-Server lief das ohne Probleme, auch die Testversion auf meiner Domain bei 1&1 funktionierte.
Nur auf dem Server meines Auftraggebers funktionieren die Anker nicht (er hat definitiv eine 1:1-Kopie meiner Testversion bekommen und ich habe die ihm geschickte Version zum Test ebenfalls wieder bei mir auf dem Server installiert - da gingen die Anker auch wieder).

Der Server ist irrelevant.

Der Fragment Identifier (#irgendwas) wird NICHT an den Server gesandt, er ist auch kein Bestandteil der URL.
Der Fragment Identifier wird ausschließlich vom Client ausgewertet.
Dort ist das Problem zu suchen.

cu,
Andreas