Discussion :

[Leobaillard]

Bonjour !

Je ne savais pas bien dans quelle section je devais poster ce message, alors je m'adresse ici pour commencer.

J'ai une page qui contient un formulaire, hébergée sur un serveur Apache. On y accède en https via SSL. Seulement, lorsque j'envoie le formulaire avec les bons identifiants, j'obtiens une page blanche avec pour tout code source :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

</div>

C'est un formulaire de connexion pour mon site qui, si le couple login/mot de passe est bon, redirige vers la page d'accueil en http non sécurisé. Peut-etre que le problème vient de là ? J'ai oublié de préciser que ce problème ne survient pas si le couple d'identifiant n'est pas bon (je suis dans ce cas bien redirigé vers une page d'erreur, toujours en http sécurisé), ou lorsque j'accède à ce formulaire depuis un lieu où il n'y a pas de proxy. Le proxy sur lequel j'ai testé est celui de mon lycée. Je ne sais pas très bien ce qu'il est exactement mais je pense que c'est un SQUID.

Si quelqu'un a déjà eu un problème similaire ou connait la réponse...

Merci d'avance !

[_Mac_]

Comment fais-tu ta redirection et qu'elle est l'URL de la page blanche (essaie avec Firefox pour nous donner cette URL plutôt qu'IE, il est plus précis ) ?

[Leobaillard]

Pour la redirection j'utilise la fonction header de php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<?php
header( 'Location: http://<site>/accueil.html' );
?>

L'adresse de la page est (je n'utilise que Firefox de toutes façons ) https://<site>/connexion.html

PS : Je préfère ne pas donner l'adresse exacte car je ne souhaite pas qu'elle soit référencée pour le moment car le site est en création.

[_Mac_]

Pas de souci, c'était pour savoir si tu faisais une redirection en relatif ou en absolu. Là, c'est de l'absolu (http://...), donc logiquement, elle doit bien fonctionner. La seule chose qu'il faut que tu vérifies c'est qu'il n'y a pas de code HTML ou header "200 OK" envoyé en plus de cette demande de redirection. Si c'est bien le cas, c'est effectivement le proxy qui pose problème.

Pour tester avec d'autres proxies, si tu as Internet chez toi, essaie de passer par le proxy de ton FAI ou un proxy public.

T'est-il possible d'utiliser une extension Firefox du style LiveHTTPHeaders pour analyser les échanges entre le navigateur et le proxy ? Dans ce cas, il faudrait que tu nous envoies la trace obtenue quand tu as ce problème.

[Leobaillard]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
https://<site>/connexion.html 
POST /connexion.html HTTP/1.1 
Host: <site> 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6 
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 
Accept-Encoding: gzip,deflate 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
Keep-Alive: 300 
Connection: keep-alive 
Referer: https://<site>/connexion.html 
Cookie: PHPSESSID=efbc127b58ca819ce2fa1181060023e3 
Proxy-Authorization: Basic bC4uYmFpbGxhcjp4dm5INThkVg== 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 98 
connexion%5Bpseudo%5D=L%C3%A9obaillard&connexion%5Bmdp%5D=<passe>&conenxion%5Bsubmit%5D=Connexion
 
HTTP/1.x 500 Internal Server Error 
Date: Mon, 31 Mar 2008 13:26:16 GMT 
Server: Apache 
Expires: Thu, 19 Nov 1981 08:52:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Pragma: no-cache 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Set-Cookie: PHPSESSID=61def675b1f8e1c0fc1bf8b883221882; path=/ 
Connection: close 
Transfer-Encoding: chunked 
Content-Type: text/html; charset=utf-8

Visiblement, une 500 est renvoyée... Mais je n'ai aucun message d'erreur. Je suis actuellement au bahut. Je regarde les logs une fois à la maison et je teste un autre proxy, je te tiens au courant. Merci de ton aide !

[_Mac_]

Si t'as accès aux logs d'erreur d'Apache, tu devrais trouver des infos sur l'erreur. Sinon, pas de chance, faut deboguer à l'aveugle

[Leobaillard]

Voilà l'erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<ip_bahut> - - [31/Mar/2008:15:26:16 +0200] "POST /connexion.html HTTP/1.1" 500 32 "https://<site>/connexion.html" "Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.6) Gecko/20071008 Ubuntu/7.10 (gutsy) Firefox/2.0.0.6"

On n'en apprend pas vraiment plus... :/ On sait juste qu'il y a erreur 500 et qu'elle ne s'affiche pas dans le navigateur. Une idée ?

[_Mac_]

Ca, c'est la trace d'accès, pas la trace d'erreur (error_log) : y a-t-il qqch dans le fichier error_log ?

[Leobaillard]

Oui ça je sais, mais rien dans le log d'erreurs :/ C'est le seul endroit où j'ai vu la mention de l'erreur 500 :/

[_Mac_]

Arf... C'est quoi la techno qui se cache derrière connexion.html ? Y a pas moyen que ce truc crache des logs dans un fichier ?

[Leobaillard]

C'est du PHP. Ouais je vais essayer de faire un fichier de log pour voir...

[Leobaillard]

Pas d'idée ? Ce problème vient de se reproduire depuis la connexion d'un pote à moi, sans proxy et cette fois pas en HTTPS, mais en HTTP. Il ne peut tout simplement pas accéder au site :/

[_Mac_]

Avec le seul même </div> ? Tu as avancé dans l'histoire des traces ?

[Leobaillard]

Ouais, j'ai fait une sorte de log. Avec l'histoire de mon pote, en HTTP, ça s'arrête à un truc de session, je vais regarder. Mais pour le bahut, j'ai pas encore pu regarder.

[_Mac_]

C'est quoi le navigateur et l'OS de ton pote testeur ?

[Leobaillard]

Il est sous Debian et Iceweasel. Mais ça ne lui fait pas tout le temps. Je penche plutôt pour un blème côté serveur, un truc mal codé qui ferait que la session n'a pas été conservée ou un binz du genre. Je vais chercher. Mais côté bahut, toujours pas d'idée... Peut-être que c'est aussi un problème au niveau des sessions, mais je ne vois pas bien lequel cela pourrait être. Je regarderai à la rentrée.

[Leobaillard]

Il y a des nouvelles... J'ai encore amélioré le log. C'est peut-être bien le même problème qu'au bahut finalement. Ça n'a pas l'air d'avoir un rapport avec le proxy. La ligne incriminée contient une requête SQLite... Allez savoir pourquoi ça foire :/ Seulement, il y a un autre mystère ! Pourquoi suis-je épargné ?

Je tiens quand même à préciser que les autres requêtes SQLite de la page sont exécutées normalement... Je vais étudier cette ligne, et si je ne trouve pas l'erreur, je la poste ici.