Htaccess för gamla browsers?

[claudiomarino]

Jag skulle vilja skicka besökare som använder uråldriga browsers till en alternativ sida av en sajt jag byggt. Jag har ingen tidigare erfarenhet an .htaccess men tror att det är precis vad jag behöver. Efter att ha googlat runt så hittade jag följande kod. dessvärre funkar den inte all i sitt nuvarande utförande (det blir bara Internal Server Error i samtliga browsers). Är det någon som kan se var det är för fel eller kan komma med en fungerande kod så skulle jag vara ytterst tacksam.

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} Opera/[1-3] [or]
RewriteCond %{HTTP_USER_AGENT} Safari/[1-6] [or]
RewriteCond %{HTTP_USER_AGENT} Navigator/ [or]
RewriteCond %{HTTP_USER_AGENT} MSIE [1-6] [or]
RewriteRule .? upgrade.html [L]

[nitro2k01]

Problemet ligger i MSIE [1-6] där mellanslaget tolkas som en separator. Escape:a! MSIE\ [1-6]

Men det där är en dum idé rakt igenom. Du kommer få falska träffar och irriterade användare som följd. Det förekommer att webbläsare slänger in MSIE 6.0 och annat för att lura dumma webbservrar. Exempel:
Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows 95) Opera 7.03 [de]

Notera också att medan det knappast finns några IE 1.0-användare kvar i omlopp så matchar uttrycker MSIE [1-6] även Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Ett liknande problem gäller även för Opera-regeln, som matchar Opera 10 och framåt.

Ett annat problem är Safari/[1-6] som oavsiktligt matchar slutet på följande rad:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5

Helt enkelt, dum idé. Oroa dig inte så mycket för folk som sitter med gamla webbläsare. User agent-strängen är en enda röra och du måste verkligen hålla tungan rätt i mun för att inte göra liknande misstag. Lägg energin på att se till att man åtminstone hjälpligt kan läsa text på din sida om man har en för gammal läsare.

[claudiomarino]

Tack för ditt svar! Oavsett huruvida det är en bra idé eller ej så vill jag åtminstone få det att fungera. Således valde jag med koden nedan att enbart utesluta Safari 5. Men det resulterar i att man ser sidan i Safari 5 (dock utan CSS) medan man i Chrome gör en redirect

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} Safari/[5] [NC]
RewriteRule .* http://www.redirecthere.com/ [L]

[nitro2k01]

Vill du göra en redirect eller en omskrivning? Din nuvarande regel är en omskrivning, (rewrite) vilket gör att den när du fixar komma åt någon sida där .htaccessen ligger, så skickar servern istället tillbaka sida 2. Det vill säga, adressen i adressfältet förändras inte. En redirect å andra sidan gör att servern ber webbläsaren att ladda en annan sida. För att göra en sådan, lägg till R=301 till argumentet. Detta är att rekommendera om sidan ligger på en annan domän.
[kod]RewriteRule .* http://www.redirecthere.com/ [R=301,L][/kod]

Men det behöver nödvändigtvis inte vara anledningen till att det inte funkar. Till att börja med så är det möjligt att både Safari och Chrome matchar din regel ovan, eftersom en modern version av Chrome innehåller en sådan sträng. Min Chrome user agent innehåller Safari/537.36 t ex.

Det finns en annan sak att ta hänsyn till här, för att förvirra saker ytterligare, nämligen cachen. Normalt sett frågar webbläsaren servern när en vissa sida uppdaterades senast. Låt oss säga att du senaste uppdaterade filerna i ordningen, först CSS'en, sedan upgrade.html sedan index.html (t ex). Du besöker sidan en gång i dess normaltillstånd, och webbläsaren (Safari i detta fall) sparar respektive datum i sin cache.

Nu lägger du till reglerna i din .htaccess och besöker framsidan. Safari ber om senaste datum för index.html. Utan att Safari vet något om det svarar servern med datumet för upgrade.html (pga rewriten). Eftersom det datumet är äldre så väljer Safari att inte ladda om hela sidan från servern.

Safari frågar sedan om CSS-filen. Av samma anledning som ovan svarar servern med datumet för upgrade.html (återigen utan att Safari vet om att datumet tillhör upgrade.html). Eftersom datumet för upgrade.html är nyare än datumet för CSS-filen så väljer Safari att ladda om CSS-filen. Men pga rewriten får Safari tillbaka en HTML-fil istället för CSS-filen, och alltså visas sidan utan CSS.

Chrome istället valde att ladda om framsidan och visade upgrade.html istället för index.html.

Jag vet inte exakt om det gick till så, men det är den bösta förklaringen jag kan komma på. Prova att ladda om sidan i Safari och se om du ser upgrade.html.

Ett sätt att komma runt problemet är att inte göra omskrivningen för statiska filer. Du kan antingen lägga all statiska filer i samma katalog, eller matcha på filändelse.

Om alla statiska filer ligger i samma katalog:
[kod]RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} Safari/[5] [NC]
RewriteCond %{REQUEST_URI} !^/static/ [NC]
RewriteRule .* http://www.redirecthere.com/ [L][/kod]
eller baserat på filändelse:
[kod]RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} Safari/[5] [NC]
RewriteCond %{REQUEST_URI} !\.(js|css|gif|png|jpe?g)$ [NC]
RewriteRule .* http://www.redirecthere.com/ [L][/kod]Utropstecknet negerar matchningen.