"Fel av typen 2" på vissa websidor?

Har för mig att de bygger på samma renderingsmotor, så det är inte konstigt att resultatet blir detsamma.

I alla fall, det finns faktiskt ett fel i det där små sid-länkarna.
"showthread.php?t=57557&page=1"

Där det nu står "&" så ska det faktiskt vara ett &-tecken och inget annat. Felet borde resultera i att sidan inte hittas ordentligt, och inte att programmet kraschar, men men...

Det står "showthread.php?t=57557&page=1" i koden till 99mac.

Även Safari översätter "&" till "&" både i vänsterhörnet (vid mouseover) och när den skickar requesten till servern. Netscape gör det väl antagligen inte?

Om du inte är inne på html, så kan jag nämna att "&" är html-koden för "&".
Det är alltså ett fel i 99macs kod, vilket de säkert kan åtgärda om man hojtar på dom, men samtidigt är det en bugg i programmen som gör att dom rasar.

Feltyp 2 - dsAddressErr - address error

Fel av typen 2 är väl ett minnesfel? Det är definitivt inte ett fel i URL'en varje fall.
Har du provat öka minnestilldelningen till browsern?

showthread.php?t=57557&page=1
Det är korrekt att skriva & enligt webstandard.

Adresseringsfel i minnet.

Både "&" och ";" har specialbetydelse i URL:er, vilket inte har med HTML att göra.

Exakt. Vilket då alltså inte har något med hemsidans kodning att göra, vilket jag lite fick intrycket av och vilket chform definitivt trodde.

Men i kod så ska man skriva & enligt standarden, det blir naturligtvis ett ampersand i en länk eller formdata.

I html-kod, ja. I URL:er, nej, även om de flesta webbläsare får det att funka ändå. Som sagt, både & och ; har andra betydelser i en URL.

Min tanke var att ovanstående lilla kodfel skapar minnesfel i nämnda webbläsare eftersom den inte konverterar & till &.

Vi är överens om att det är ett minnesfel som får browsern att krascha, däremot bråkar vi om huruvida det är korrekt att skriva & i URL:er

Minnesfel helt klart.

Vi snackar säkert i cirklar och jag förstår inte vad du menar.
Om man skriver en länk i html-kod ska den skrivas
whatever.php?a=1&b=2 och inte
whatever.php?a=1&b=2

Slutresultatet i webläsaren bör bli samma (whatever.php?a=1&b=2) men det första är det korrekta sättet att skriva länken.

Tillägg innan jag drar på lunch:
W3 org specen som rör detta: http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2

Om du ska skriva ut länken på skärmen, ja, dvs <a>whatever.php?a=1&b=2</a>

Men i själva URL:en, alltså href, ska det vara <a href="whatever.php?a=1&b=2">...</a>

Kodningen för HTML och URL är helt olika saker, och hanterar specialtecken på olika sätt.

EDIT: Sidan du letat upp berör hanteringen av URL:er i formulär, inte i <a href>.

Första exemplet har jag ersatt med [...] då jag inte verkar få till att posta som det står på W3orgs sida.

Jag blir faktiskt nyfiken på om jag har fel, kan du posta en länk som understödjer vad du säger?

http://www.ietf.org/rfc/rfc2396.txt

2.2. Reserved Characters

Many URI include components consisting of or delimited by, certain
special characters. These characters are called "reserved", since
their usage within the URI component is limited to their reserved
purpose. If the data for a URI component would conflict with the
reserved purpose, then the conflicting data must be escaped before
forming the URI.

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

Dessa tecken har alltså en speciell betydelse i URI.er, de används som sk delimiters (skiljer ut delar av URI:n).

"&;"-konstruktionen i HTML är för att hantera speciella tecken, motsvarigheten i URI-kodning är "%" (exempelvis %20 för mellanslag). "&" används för att skilja ut namn-data-par ur URI:ns sökdel, ";" används för att dela upp data-element i en lista.

Nej. I gamla medeltida HTML 4 är det ok, men i XHTML är det alldeles jättefel oavsett var i dokumentet det förekommer. Samma sak med &-tecken i inbäddade javascript, det är bara tillåtet inom CDATA-sektioner. Anledningen är att "&" är reserverat för kodning av specialtecken, och det får därför inte förekomma på egen hand någonstans i koden. XHTML är betydligt mer rationellt på det sättet, eftersom det inte finns några kontextberoende "specialregler" längre - samma syntax gäller helt enkelt överallt.

Just ja, för den som vill kolla upp saken närmre så finns det faktiskt en särskild kommentar i själva XHTML-standarden från W3C, som tar upp just URL:er och &-tecken:

(från http://www.w3.org/TR/xhtml1/#C_12)

Men det där motsätter ju inte det faktum att när du skriver url'en ska du koda '&', dvs du ska skriva &. Det säger ju bara att '&' har särskild betydelse i URL'en vilket är irrelevant (och självklart i sammanhanget), när du länkar ska du skriva & enligt den specen jag länkade, och 99mac's sätt att skriva i sin kod (oftast, koden är inte konsekvent).

Om vi ska komma tillbaka till det faktiska problemet här och vänta lite med W3C:s specifikationer så är min gissning att det tyvärr inte är så mycket att göra om det inte hjälper med att utöka minnet. Troligen är det en miss i programmeringen och dessa webläsare uppdateras inte längre för Mac OS 9. Kolla att du har senaste versionen, är allt jag kan råda dig till.

Edit: Annars kanske någon kan lägga upp en testsida på egen server och se om det verkligen är det vi tror som är felet.

Ledsen för stickspåret men det är väl utrett nu

Det är inte något nytt att skriva länkar med varesig '&' eller & så jag tror knappast det är felet på något sätt.

Jag funderade om webläsarna av någon anledning kanske sög upp en jävla massa minne på endera sida pga långa trådar eller särskilda annonser eller något. Men som sagt, vi får se om det blir någon skillnad efter ökning av minnet.