r14372 - spip/ecrire/public

Notifications Commit Core
1

Author: esj@rezo.net
Date: 2009-08-10 07:46:25 +0200 (lun, 10 aoû 2009)
New Revision: 14372

Log:
Suite de [14371]: ne pas arrêter la compilation au premier critère incorrect, mais introduction de la valeur False comme type de requête dans l'arbre de syntaxe pour être capable de provoquer un 503 au final. Il faudrait abandonner l'usage d'une globale (tableau_des_erreurs) pour mémoriser toutes les erreurs, car elle ne dit pas si les erreurs viennent du squelette en cours de compilation ou d'autres précédemment inclus.

Modified:
   spip/ecrire/public/compiler.php

Details: http://trac.rezo.net/trac/spip/changeset/14372

2

valeur False comme type de requête dans l'arbre de syntaxe pour être capable de provoquer un 503 au final.

Si je lis bien la norme, 503 est un code de retour indiquant un
problème temporaire de surcharge ; rien à voir donc avec une faute de
syntaxe, qui devrait plutôt être 500.

-- Fil

3

Le 10 août 09 à 09:29, Fil a écrit :

valeur False comme type de requête dans l'arbre de syntaxe pour être capable de provoquer un 503 au final.

Si je lis bien la norme, 503 est un code de retour indiquant un
problème temporaire de surcharge ; rien à voir donc avec une faute de
syntaxe, qui devrait plutôt être 500.

Pour 503, le RFC dit:

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.

donc pas seulement de la surcharge, aussi de la maintenance et ça me parait mieux que le 500 "internal server error" qui semble accuser la totalité du serveur Http et ses dépendances (SPIP ici): il vaut mieux dire qu'un service très précis rendu par un squelette est en cours de maintenance.

perdre un de ces automatismes dont SPIP a le secret et qui
fait que "ça marche". Je ne suis pas pour.

</BOUCLE_principale>[(#INCLURE{fond=404, erreur=<:aucun_TRUC:>})]
<//B_principale>

bof ; le mécanisme actuel me paraît bien plus simple, et pour les
puristes qui veulent *vraiment* un corps vide il est débrayable.

c'est moins le corps vide qui me préoccupe que l'implication fausse:
"page vide + id_article dans l'URL ==> erreur article inconnu"
ma proposition est de virer cette tentative de précision du pourquoi de la page vide,
dont je répète que la disparition pendant 16 mois n'a gêné personne,
et de le gérer seulement dans les squelettes canoniques article, rubrique etc.

Pour le reste, continuer à faire un 404, je ne suis pas fana mais par souci de compatibilité ok.

il me semble
que les cas "mal écrit" et "squelette inconnu" entrent dans la
catégorie "erreur de programmation" (50x),

"mal écrit" oui, mais "inconnu" ça peut être le visiteur qui écrit "page=faute_de_frappe" ou une URL d'un truc dépublié, ce ne sont pas des fautes de programmation, SPIP et l'auteur des squelettes ne sont pas en cause. C'est vrai que 404 est pas totalement satisfaisant mals le reste non plus:
pour l'URL dépublié il faudrait 410 (Gone) mais c'est pas toujours facile à déterminer, et je verrais un 204 pour un squelette avec un id d'objet inexistant, en réservant le 404 au squelette inconnu; mais les URL propres rendent cette classification impossible à faire.

Committo,Ergo:Sum

4

donc pas seulement de la surcharge, aussi de la maintenance et ça me parait
mieux que le 500 "internal server error" qui semble accuser la totalité du
serveur Http et ses dépendances (SPIP ici): il vaut mieux dire qu'un service
très précis rendu par un squelette est en cours de maintenance.

comme tu vois ça se discute, mais ta proposition est acceptable

c'est moins le corps vide qui me préoccupe que l'implication fausse:
"page vide + id_article dans l'URL ==> erreur article inconnu"
ma proposition est de virer cette tentative de précision du pourquoi de la
page vide,

..

et de le gérer seulement dans les squelettes canoniques article, rubrique
etc.

ok ta proposition est plus clean de ce point de vue

dont je répète que la disparition pendant 16 mois n'a gêné personne,

faux : j'ai commité là-dessus quand je me suis aperçu que ça avait
disparu ; mais suite à certaines modifs je ne savais plus le faire que
dans certains cas d'urls, pas dans tous.

Pour le reste, continuer à faire un 404, je ne suis pas fana mais par souci
de compatibilité ok.

good

"inconnu" ça peut être le visiteur qui écrit
"page=faute_de_frappe" ou une URL d'un truc dépublié, ce ne sont pas des
fautes de programmation, SPIP et l'auteur des squelettes ne sont pas en
cause. C'est vrai que 404 est pas totalement satisfaisant mals le reste non
plus:

ok pour 404 dans ce cas donc

pour l'URL dépublié il faudrait 410 (Gone) mais c'est pas toujours facile à
déterminer, et je verrais un 204 pour un squelette avec un id d'objet
inexistant, en réservant le 404 au squelette inconnu; mais les URL propres
rendent cette classification impossible à faire.

sur 204 pas d'accord : le texte de la norme indique qu'il s'agit de
traiter le cas où le résultat d'une interaction (formulaire) ne
modifie pas la page. 204 indique au navigateur *de continuer à
afficher la page précédente*.

-- Fil

5

Le 10 août 09 à 10:47, Fil a écrit :

ma proposition est de virer cette tentative de précision du pourquoi de la
page vide,

..

et de le gérer seulement dans les squelettes canoniques article, rubrique
etc.

ok ta proposition est plus clean de ce point de vue

dont je répète que la disparition pendant 16 mois n'a gêné personne,

faux : j'ai commité là-dessus quand je me suis aperçu que ça avait
disparu ; mais suite à certaines modifs je ne savais plus le faire que
dans certains cas d'urls, pas dans tous.

Bah oui, d'où le constat que SPIP est à présent trop général pour se permettre des automatismes comme ça, et que c'est aux squelettes de gérer la situation.

Committo,Ergo:Sum

6

Le 10 août 09 à 10:23, Committo,Ergo:sum a écrit :

dont je répète que la disparition pendant 16 mois n'a gêné personne,

disons que pour ma part je pensais le bug chez moi sans le trouver (mais à chercher... plus tard, c'est vrai)

Claude