2009-03-11 7 views
4

J'utilise .htaccess pour accélérer un site avec les réoriente suivantes:le site 5x plus rapide via mod_rewrite, mais les images CSS sont brisées

request for http://example.com/images/name.jpg routed to http://i.example.com/name.jpg 
request for http://example.com/css/name.css  routed to http://c.example.com/name.css 

En écoutant le podcast Stack Overflow, j'ai appris que cela pourrait faire une site plus rapide, puisque le navigateur peut télécharger plusieurs fichiers simultanément (apparemment deux flux par domaine, même si cela n'est pas confirmé).

En effet, la différence est dramatique; la page charge environ cinq fois plus vite!

Je n'ai pas touché les dossiers et images originales - Je suis juste en utilisant mod_rewrite pour changer les adresses de example.com/images/ à i.example.com/:

 
rewritecond %{HTTP_HOST}  !^i\.example\.com  [NC] 
rewriterule ^images/([^/]+)$ http://i.example.com/$1 [L] 
rewritecond %{HTTP_HOST}  !^c\.example\.com  [NC] 
rewriterule ^css/([^/]+)$ http://c.example.com/$1 [L] 

le problème que j'ai est que cette technique fonctionne parfaitement pour les balises d'image inclus dans html, mais ne fonctionne pas pour les images incluses via: stylesheets

img src =/images/logo.jpg fonctionne parfaitement

fond: url (/images/logo.jpg); ne fonctionne pas

Le journal des erreurs de serveur contient l'entrée suivante:

fichier n'existe pas:/var/www/html/css/images, Referer: http://example.com/page.html

Cela semble impliquer que la règle de réécriture est appliquée incorrectement.

Les feuilles de style fonctionnent si j'utilise:

background: url (http://i.example.com/logo.jpg);

Cependant, afin d'éviter de réécrire toutes les feuilles de style, je voudrais savoir: pourquoi ne pas l'URL rewriting appliquer à StyleSheets comme il le fait à des balises HTML img.

[Update1] Ce problème existe dans Safari 4 Beta, Firefox 3.0.3 et Chrome, mais la page fonctionne parfaitement dans IE6. Ajout de [L, R = 301] et [L, R = 302] n'a pas aidé.

[Update3] J'ai essayé ce qui suit en fonction de la suggestion de Gumbo ci-dessous:

Redirect extérieur si le chemin ne correspond pas au nom d'hôte:

rewritecond %{HTTP_HOST}  !^i\.domain\.com$ 
rewriterule ^images/([^/]+)$ http://i.domain.com/$1 [L,R=301] 
rewritecond %{HTTP_HOST}  !^c\.domain\.com$ 
rewriterule ^css/([^/]+)$ http://c.domain.com/$1 [L,R=301] 

Redirect interne; s'il y a un nom de dossier inutile, supprimez-le (voir erreur du serveur ci-dessus):

rewritecond %{HTTP_HOST}  ^i\.domain\.com$ 
rewriterule ^images/([^/]+)$ $1 [L] 
rewritecond %{HTTP_HOST}  ^c\.domain\.com$ 
rewriterule ^css/([^/]+)$ $1 [L] 

Cela ne fonctionnait toujours pas. Bizarrement, l'erreur du serveur est:

fichier n'existe pas:/var/www/html/css/var, referer: http://domain.com/page.html

+0

Utilisez-vous réellement des chemins absolus dans la feuille de style? – Gumbo

+0

Eh bien, la seule explication de ce comportement est que le chemin relatif "images/foo" dans la feuille de style "/ css/bar" est (correctement) résolu en "/ css/images/foo". L'utilisation de chemins absolus à la place résoudrait ce problème. – Gumbo

+0

Je suis retourné et vérifié, et ils sont vraiment des chemins absolus. Puisque le comportement change dans différents navigateurs, cela peut avoir quelque chose à voir avec la façon dont les navigateurs essaient d'interpréter les images CSS pour des raisons de mise en cache. J'ai aussi essayé ../images et ../../images, toujours cassé. –

Répondre

1

j'ai pu résoudre ce problème en pas essayer d'incorporer répertoires dans les sous-domaines:

 
request for domain.com/images/ routed to i.domain.com/images/ 
request for domain.com/css/  routed to c.domain.com/css/ 

Il fonctionne parfaitement et est encore extrêmement rapide.

Il semble y avoir un bug dans les navigateurs modernes où une demande de css qui est redirigée sera appliquer que le nouveau domaine, laissant les répertoires d'origine dans le cadre de la demande:

Si une image css à url (domain.com/images/name.jpg) est redirigé vers i.domain.com/name.jpg, le navigateur demandera à tort i.domain.com/images/name.jpg.

1

je trouve un moyen de résoudre ce problème si tous les noms d'hôtes utilisent le même hôte virtuel:

# redirect externally if path doesn’t match host name 
RewriteCond %{HTTP_HOST} !^i\.example\.com$ 
RewriteRule ^images/([^/]+)$ http://i.example.com/$1 [L,R=301] 
RewriteCond %{HTTP_HOST} !^c\.example\.com$ 
RewriteRule ^css/([^/]+)$ http://c.example.com/$1 [L,R=301] 

# redirect internally to the file 
RewriteCond %{HTTP_HOST} ^i\.example\.com$ 
RewriteRule !^images/ images%{REQUEST_URI} [L] 
RewriteCond %{HTTP_HOST} ^c\.example\.com$ 
RewriteRule !^css/ css%{REQUEST_URI} [L] 

Cela procédez comme suit:

http://example.com/css/foo  externally to http://c.example.com/foo 
http://c.example.com/foo   internally to /css/foo 

http://example.com/images/bar externally to http://i.example.com/bar 
http://i.example.com/bar   internally to /images/bar 

En plus de corriger les chemins désadaptation et hôte noms:

http://i.example.com/css/foo  externally to http://c.example.com/foo 
http://c.example.com/images/bar externally to http://i.example.com/bar 

Un décalage se produit lorsque la feuille de style demandé http://example.com/css/foo est redirigé vers http://c.example.com/foo et une référence d'image URI comme /images/bar à l'intérieur de la feuille de style est résolue à partir de ce nouvel URI de base et conduit ainsi à http://c.example.com/images/bar au lieu du http://example.com/images/bar initial.

+0

Cette solution remappe http://i.example.com/bar interne à/images/bar, pas ce dont j'ai besoin. Ce que je pensais résoudre le problème initial était de remapper http://i.example.com/images/bar à http://i.example.com/bar. Cela n'a pas fonctionné (voir la question révisée). –