J'ai un serveur web sur une machine, dont le repertoire /var/www est
monté en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en
ouvrant simplement avec firefox /mnt/www/monfichier.htm), le fichier
apparait correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme
fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale
fr_FR.ISO-8859-15@euro, alors je ne comprends pas trop d'ou cela peut venir.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Guillaume REMY
Bonsoir,
J'ai un serveur web sur une machine, dont le repertoire /var/www est monté en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en ouvrant simplement avec firefox /mnt/www/monfichier.htm), le fichier apparait correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale , alors je ne comprends pas trop d'ou cela peut venir.
J'ai un serveur web sur une machine, dont le repertoire /var/www est
monté en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en
ouvrant simplement avec firefox /mnt/www/monfichier.htm), le fichier
apparait correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme
fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale
fr_FR.ISO-8859-15@euro, alors je ne comprends pas trop d'ou cela peut
venir.
J'ai un serveur web sur une machine, dont le repertoire /var/www est monté en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en ouvrant simplement avec firefox /mnt/www/monfichier.htm), le fichier apparait correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale , alors je ne comprends pas trop d'ou cela peut venir.
Dans le message <news:uECdd.7626$, *Guillaume REMY* tapota sur f.c.o.l.configuration :
Bonsoir,
Bonsoir,
J'ai un serveur web sur une machine, dont le repertoire /var/www est monté en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en ouvrant simplement avec firefox /mnt/www/monfichier.htm), le fichier apparait correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale ,
Peu importe, vos locales n'ont pas à intervenir sur le contenu de vos fichiers HTML. Le client doit afficher les pages HTML en utilisant le charset défini dans les en-têtes des fichiers ou le charset envoyé par le serveur Web dans ses en-têtes.
alors je ne comprends pas trop d'ou cela peut venir.
Du serveur Web tout simplement ? En particulier si la distribution est une Red Hat ou une Fedora.
Une idée ?
Vérifiez les en-têtes envoyés par le serveur Web (telnet serveur 80). S'il force l'encodage des pages dans un charset particulier, vérifiez alors sa configuration, par exemple, dans le cas de Apache, l'option AddDefaultCharset.
Merci !
De rien.
-- TiChou
Dans le message <news:uECdd.7626$1p.6415@nntpserver.swip.net>,
*Guillaume REMY* tapota sur f.c.o.l.configuration :
Bonsoir,
Bonsoir,
J'ai un serveur web sur une machine, dont le repertoire /var/www est monté
en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en ouvrant
simplement avec firefox /mnt/www/monfichier.htm), le fichier apparait
correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme
fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale
fr_FR.ISO-8859-15@euro,
Peu importe, vos locales n'ont pas à intervenir sur le contenu de vos
fichiers HTML. Le client doit afficher les pages HTML en utilisant le
charset défini dans les en-têtes des fichiers ou le charset envoyé par le
serveur Web dans ses en-têtes.
alors je ne comprends pas trop d'ou cela peut venir.
Du serveur Web tout simplement ? En particulier si la distribution est une
Red Hat ou une Fedora.
Une idée ?
Vérifiez les en-têtes envoyés par le serveur Web (telnet serveur 80). S'il
force l'encodage des pages dans un charset particulier, vérifiez alors sa
configuration, par exemple, dans le cas de Apache, l'option
AddDefaultCharset.
Dans le message <news:uECdd.7626$, *Guillaume REMY* tapota sur f.c.o.l.configuration :
Bonsoir,
Bonsoir,
J'ai un serveur web sur une machine, dont le repertoire /var/www est monté en nfs sur une autre machine en /mnt/www.
Lorsque je visualise un fichier HTML depuis la seconde machine (en ouvrant simplement avec firefox /mnt/www/monfichier.htm), le fichier apparait correctement.
Lorsque par contre je passe par le serveur web pour visualiser le meme fichier, les accents, cédiles, etc ne passent pas.
J'ai pourtant configuré les deux machines pour utiliser la locale ,
Peu importe, vos locales n'ont pas à intervenir sur le contenu de vos fichiers HTML. Le client doit afficher les pages HTML en utilisant le charset défini dans les en-têtes des fichiers ou le charset envoyé par le serveur Web dans ses en-têtes.
alors je ne comprends pas trop d'ou cela peut venir.
Du serveur Web tout simplement ? En particulier si la distribution est une Red Hat ou une Fedora.
Une idée ?
Vérifiez les en-têtes envoyés par le serveur Web (telnet serveur 80). S'il force l'encodage des pages dans un charset particulier, vérifiez alors sa configuration, par exemple, dans le cas de Apache, l'option AddDefaultCharset.
Merci !
De rien.
-- TiChou
TiChou
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Une idée ?
Vérifiez les en-têtes envoyés par le serveur Web (telnet serveur 80). S'il force l'encodage des pages dans un charset particulier, vérifiez alors sa configuration, par exemple, dans le cas de Apache, l'option AddDefaultCharset.
J'oubliais une chose ! Vérifiez aussi que dans vos fichiers HTML comportent bien l'en-tête suivant :
Avec xxxx qui doit être le charset qui a été utilisé pour créer ces fichiers HTML.
-- TiChou
Dans le message <news:gniii.20041021014055@florizarre.tichou.org>,
*TiChou* tapota sur f.c.o.l.configuration :
Une idée ?
Vérifiez les en-têtes envoyés par le serveur Web (telnet serveur 80). S'il
force l'encodage des pages dans un charset particulier, vérifiez alors sa
configuration, par exemple, dans le cas de Apache, l'option
AddDefaultCharset.
J'oubliais une chose ! Vérifiez aussi que dans vos fichiers HTML comportent
bien l'en-tête suivant :
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Une idée ?
Vérifiez les en-têtes envoyés par le serveur Web (telnet serveur 80). S'il force l'encodage des pages dans un charset particulier, vérifiez alors sa configuration, par exemple, dans le cas de Apache, l'option AddDefaultCharset.
J'oubliais une chose ! Vérifiez aussi que dans vos fichiers HTML comportent bien l'en-tête suivant :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> ^^^^^^^^^^
Le serveur Apache semble tenir compte du charset défini dans la page. Peut-être simple coïncidence.
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver toutes ces infos... et je suis content, car j'ai trouvé :) Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete ce soir... enfin ce matin...
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a été encodé en UTF-8, et contient bien l'entete : <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Et l'option AddDefaultCharset est activée : # Default charset to iso-8859-1. AddDefaultCharset on Mais de toute facon il me semble que si le charset est spécifié dans l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué dans tout ce qui est sécurité... je pensais qu'APT se chargait plus ou moins des mises à jour !
Dans le message <news:QFCdd.7627$1p.6415@nntpserver.swip.net>,
*Guillaume REMY* tapota sur f.c.o.l.configuration :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
^^^^^^^^^^
Le serveur Apache semble tenir compte du charset défini dans la page.
Peut-être simple coïncidence.
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour
trouver toutes ces infos... et je suis content, car j'ai trouvé :)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins
bete ce soir... enfin ce matin...
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas
a été encodé en UTF-8, et contient bien l'entete :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Et l'option AddDefaultCharset est activée :
# Default charset to iso-8859-1.
AddDefaultCharset on
Mais de toute facon il me semble que si le charset est spécifié dans
l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué
dans tout ce qui est sécurité... je pensais qu'APT se chargait plus ou
moins des mises à jour !
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> ^^^^^^^^^^
Le serveur Apache semble tenir compte du charset défini dans la page. Peut-être simple coïncidence.
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver toutes ces infos... et je suis content, car j'ai trouvé :) Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete ce soir... enfin ce matin...
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a été encodé en UTF-8, et contient bien l'entete : <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Et l'option AddDefaultCharset est activée : # Default charset to iso-8859-1. AddDefaultCharset on Mais de toute facon il me semble que si le charset est spécifié dans l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué dans tout ce qui est sécurité... je pensais qu'APT se chargait plus ou moins des mises à jour !
TiChou
Dans le message <news:mdEdd.7629$, *Guillaume REMY* tapota sur f.c.o.l.configuration :
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver toutes ces infos... et je suis content, car j'ai trouvé :)
:-)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete ce soir... enfin ce matin...
Euh, ah oui déjà 4H du matin... Ouch !
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a été encodé en UTF-8, et contient bien l'entete : <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Ok.
Et l'option AddDefaultCharset est activée : # Default charset to iso-8859-1. AddDefaultCharset on Mais de toute facon il me semble que si le charset est spécifié dans l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et si justement ! Le serveur imposera à votre browser d'utiliser le charset iso-8859-1 sans tenir compte du charset du fichier HTML. Commentez la ligne AddDefaultCharset et relancez votre serveur Apache. Tout devrait alors rentrer dans l'ordre.
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué dans tout ce qui est sécurité...
Il suffit généralement de s'inscrire dans la mailling list sécurité de votre distribution pour être tenu informé des failles importantes.
je pensais qu'APT se chargait plus ou moins des mises à jour !
C'est le le cas ! Mais je me suis peut être avancé un peu trop vite en voyant l'en-tête Last-Modified, puisqu'il s'agit non pas de la date du serveur Web mais de la date de dernière modificiation de la page afficheé. Au temps pour moi.
Bonne nuit. ;-)
-- TiChou
Dans le message <news:mdEdd.7629$1p.6415@nntpserver.swip.net>,
*Guillaume REMY* tapota sur f.c.o.l.configuration :
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver
toutes ces infos... et je suis content, car j'ai trouvé :)
:-)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete
ce soir... enfin ce matin...
Euh, ah oui déjà 4H du matin... Ouch !
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a
été encodé en UTF-8, et contient bien l'entete :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Ok.
Et l'option AddDefaultCharset est activée :
# Default charset to iso-8859-1.
AddDefaultCharset on
Mais de toute facon il me semble que si le charset est spécifié dans
l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et si justement ! Le serveur imposera à votre browser d'utiliser le charset
iso-8859-1 sans tenir compte du charset du fichier HTML.
Commentez la ligne AddDefaultCharset et relancez votre serveur Apache. Tout
devrait alors rentrer dans l'ordre.
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué
dans tout ce qui est sécurité...
Il suffit généralement de s'inscrire dans la mailling list sécurité de votre
distribution pour être tenu informé des failles importantes.
je pensais qu'APT se chargait plus ou moins des mises à jour !
C'est le le cas ! Mais je me suis peut être avancé un peu trop vite en
voyant l'en-tête Last-Modified, puisqu'il s'agit non pas de la date du
serveur Web mais de la date de dernière modificiation de la page afficheé.
Au temps pour moi.
Dans le message <news:mdEdd.7629$, *Guillaume REMY* tapota sur f.c.o.l.configuration :
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver toutes ces infos... et je suis content, car j'ai trouvé :)
:-)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete ce soir... enfin ce matin...
Euh, ah oui déjà 4H du matin... Ouch !
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a été encodé en UTF-8, et contient bien l'entete : <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Ok.
Et l'option AddDefaultCharset est activée : # Default charset to iso-8859-1. AddDefaultCharset on Mais de toute facon il me semble que si le charset est spécifié dans l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et si justement ! Le serveur imposera à votre browser d'utiliser le charset iso-8859-1 sans tenir compte du charset du fichier HTML. Commentez la ligne AddDefaultCharset et relancez votre serveur Apache. Tout devrait alors rentrer dans l'ordre.
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué dans tout ce qui est sécurité...
Il suffit généralement de s'inscrire dans la mailling list sécurité de votre distribution pour être tenu informé des failles importantes.
je pensais qu'APT se chargait plus ou moins des mises à jour !
C'est le le cas ! Mais je me suis peut être avancé un peu trop vite en voyant l'en-tête Last-Modified, puisqu'il s'agit non pas de la date du serveur Web mais de la date de dernière modificiation de la page afficheé. Au temps pour moi.
Bonne nuit. ;-)
-- TiChou
Guillaume REMY
Dans le message <news:mdEdd.7629$, *Guillaume REMY* tapota sur f.c.o.l.configuration :
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver toutes ces infos... et je suis content, car j'ai trouvé :)
:-)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete ce soir... enfin ce matin...
Euh, ah oui déjà 4H du matin... Ouch !
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a été encodé en UTF-8, et contient bien l'entete : <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Ok.
Et l'option AddDefaultCharset est activée : # Default charset to iso-8859-1. AddDefaultCharset on Mais de toute facon il me semble que si le charset est spécifié dans l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et si justement ! Le serveur imposera à votre browser d'utiliser le charset iso-8859-1 sans tenir compte du charset du fichier HTML. Commentez la ligne AddDefaultCharset et relancez votre serveur Apache. Tout devrait alors rentrer dans l'ordre.
Merci beaucoup, c'était bien ça...
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué dans tout ce qui est sécurité...
Il suffit généralement de s'inscrire dans la mailling list sécurité de votre distribution pour être tenu informé des failles importantes.
Merci, je vais faire ca... j'ai aussi prévu de lire le manuel de
sécurisation Debian proposé sur le site de debian, mais bon, faut trouver le temps !
je pensais qu'APT se chargait plus ou moins des mises à jour !
C'est le le cas ! Mais je me suis peut être avancé un peu trop vite en voyant l'en-tête Last-Modified, puisqu'il s'agit non pas de la date du serveur Web mais de la date de dernière modificiation de la page afficheé. Au temps pour moi.
Bonne nuit. ;-)
Bonjour :)
Une derniere petite question tout de meme. J'ai réglé l'heure de mon systeme avec un date -s, mais l'heure renvoyée par apache est toujours décalée de 2 heures... Ne tient-il pas compte de l'heure du systeme ?
Merci !
Dans le message <news:mdEdd.7629$1p.6415@nntpserver.swip.net>,
*Guillaume REMY* tapota sur f.c.o.l.configuration :
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour
trouver toutes ces infos... et je suis content, car j'ai trouvé :)
:-)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins
bete ce soir... enfin ce matin...
Euh, ah oui déjà 4H du matin... Ouch !
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe
pas a été encodé en UTF-8, et contient bien l'entete :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Ok.
Et l'option AddDefaultCharset est activée :
# Default charset to iso-8859-1.
AddDefaultCharset on
Mais de toute facon il me semble que si le charset est spécifié dans
l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et si justement ! Le serveur imposera à votre browser d'utiliser le
charset iso-8859-1 sans tenir compte du charset du fichier HTML.
Commentez la ligne AddDefaultCharset et relancez votre serveur Apache.
Tout devrait alors rentrer dans l'ordre.
Merci beaucoup, c'était bien ça...
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop
doué dans tout ce qui est sécurité...
Il suffit généralement de s'inscrire dans la mailling list sécurité de
votre distribution pour être tenu informé des failles importantes.
Merci, je vais faire ca... j'ai aussi prévu de lire le manuel de
sécurisation Debian proposé sur le site de debian, mais bon, faut
trouver le temps !
je pensais qu'APT se chargait plus ou moins des mises à jour !
C'est le le cas ! Mais je me suis peut être avancé un peu trop vite en
voyant l'en-tête Last-Modified, puisqu'il s'agit non pas de la date du
serveur Web mais de la date de dernière modificiation de la page
afficheé. Au temps pour moi.
Bonne nuit. ;-)
Bonjour :)
Une derniere petite question tout de meme. J'ai réglé l'heure de mon
systeme avec un date -s, mais l'heure renvoyée par apache est toujours
décalée de 2 heures... Ne tient-il pas compte de l'heure du systeme ?
Dans le message <news:mdEdd.7629$, *Guillaume REMY* tapota sur f.c.o.l.configuration :
Bon, j'ai mis un bon moment a trouver comment vous aviez fait pour trouver toutes ces infos... et je suis content, car j'ai trouvé :)
:-)
Un peu d'etude du protocole HTTP, et du coup je vais me coucher moins bete ce soir... enfin ce matin...
Euh, ah oui déjà 4H du matin... Ouch !
Mais bon, revenons a nos moutons... en fait le fichier qui ne passe pas a été encodé en UTF-8, et contient bien l'entete : <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
Ok.
Et l'option AddDefaultCharset est activée : # Default charset to iso-8859-1. AddDefaultCharset on Mais de toute facon il me semble que si le charset est spécifié dans l'entete HTTP, le DefaultCharset n'intervient pas, si ?
Et si justement ! Le serveur imposera à votre browser d'utiliser le charset iso-8859-1 sans tenir compte du charset du fichier HTML. Commentez la ligne AddDefaultCharset et relancez votre serveur Apache. Tout devrait alors rentrer dans l'ordre.
Merci beaucoup, c'était bien ça...
Et merci pour les infos de vulnérabilité, mais je ne suis pas trop doué dans tout ce qui est sécurité...
Il suffit généralement de s'inscrire dans la mailling list sécurité de votre distribution pour être tenu informé des failles importantes.
Merci, je vais faire ca... j'ai aussi prévu de lire le manuel de
sécurisation Debian proposé sur le site de debian, mais bon, faut trouver le temps !
je pensais qu'APT se chargait plus ou moins des mises à jour !
C'est le le cas ! Mais je me suis peut être avancé un peu trop vite en voyant l'en-tête Last-Modified, puisqu'il s'agit non pas de la date du serveur Web mais de la date de dernière modificiation de la page afficheé. Au temps pour moi.
Bonne nuit. ;-)
Bonjour :)
Une derniere petite question tout de meme. J'ai réglé l'heure de mon systeme avec un date -s, mais l'heure renvoyée par apache est toujours décalée de 2 heures... Ne tient-il pas compte de l'heure du systeme ?
Merci !
Nicolas George
Guillaume REMY wrote in message <akKdd.7661$:
Une derniere petite question tout de meme. J'ai réglé l'heure de mon systeme avec un date -s, mais l'heure renvoyée par apache est toujours décalée de 2 heures... Ne tient-il pas compte de l'heure du systeme ?
Il faut lire l'heure complète, en tenant compte du fuseau horaire :
Thu, 21 Oct 2004 12:30:34 CEST Thu, 21 Oct 2004 10:30:34 GMT
sont deux écritures de la même heure.
Guillaume REMY wrote in message
<akKdd.7661$1p.6090@nntpserver.swip.net>:
Une derniere petite question tout de meme. J'ai réglé l'heure de mon
systeme avec un date -s, mais l'heure renvoyée par apache est toujours
décalée de 2 heures... Ne tient-il pas compte de l'heure du systeme ?
Il faut lire l'heure complète, en tenant compte du fuseau horaire :
Thu, 21 Oct 2004 12:30:34 CEST
Thu, 21 Oct 2004 10:30:34 GMT
Une derniere petite question tout de meme. J'ai réglé l'heure de mon systeme avec un date -s, mais l'heure renvoyée par apache est toujours décalée de 2 heures... Ne tient-il pas compte de l'heure du systeme ?
Il faut lire l'heure complète, en tenant compte du fuseau horaire :
Thu, 21 Oct 2004 12:30:34 CEST Thu, 21 Oct 2004 10:30:34 GMT
