URL-Rewriting à tendance schizophrène

WRInaute impliqué
Salut,

Voilà mon pb : je voudrais mettre en place des règles d'UR qui peuvent a priori sembler contradictoires :
  • j'ai des règles qui transforment http://monsite/truc-var1-val1-var2-val2.html en truc.php?var1=val1&var2=val2
  • mais je voudrais que ces règles d'UR soient discrètes, c-à-d qu'elles ne soient pas détectables par un internaute : je voudrais donc qu'un appel direct (via la barre d'adresse) à la page truc.php provoque une erreur 404 alors qu'un appel interne au serveur (résultant donc de la règle UR passe normalement

Est-ce possible ? Comment ?

Merci :)
 
WRInaute impliqué
Salut,

Seul un psy pourra te répondre !
:lol:

Euh balèze ce que tu demandes, je me demande si cela est bien possible.

++
 
Nouveau WRInaute
en modifiant ton script PHP.. si la page d'appel ne contient pas un .html par exemple, tu renvoie sur ton fichier d'erreur 404...

je le fait chez moi et ça marche bien.. mais bon je suis en perl et je ne connais pas trop le php ;-)
 
WRInaute accro
un moyen détourné est de ne pas nommer ta page html et php pareil :

exemple ta page php s'appelle gfdgdfgd.php, avant qu'un internaute trouve la page, de l'eau sous les pond aura coulée :)
 
WRInaute occasionnel
tu mets une variable supplémentaire (secrete), puis dans ton script php tu test si la variable existe (preuve du passage par l'UR) ça renvoi une erreur 404...
 
WRInaute impliqué
Question : un fichier .htaccess est-il ré-entrant ? En d'autres termes, si on lui met plusieurs règles, il se contente bien de lire et d'appliquer les règles dans l'ordre ? Il ne reprend pas le fichier htaccess depuis le début après chaque transformation ?

Si c'est le cas, on devrait pouvoir mettre en première règle un truc du genre :
- toute page .php (avec ou sans paramètres) renvoie à l'accueil, avec un paramètre quiprovoquera l'émission d'un en-tête 404

et en règles suivantes les règles de passage de truc-var1-... .html en truc.php?var1...

Non ?
 
WRInaute occasionnel
Non. D'après la doc de mod_rewrite,
Unbelievably mod_rewrite provides URL manipulations in per-directory context, i.e., within .htaccess files, although these are reached a very long time after the URLs have been translated to filenames. It has to be this way because .htaccess files live in the filesystem, so processing has already reached this stage. In other words: According to the API phases at this time it is too late for any URL manipulations. To overcome this chicken and egg problem mod_rewrite uses a trick: When you manipulate a URL/filename in per-directory context mod_rewrite first rewrites the filename back to its corresponding URL (which is usually impossible, but see the RewriteBase directive below for the trick to achieve this) and then initiates a new internal sub-request with the new URL. This restarts processing of the API phases.
Again mod_rewrite tries hard to make this complicated step totally transparent to the user, but you should remember here: While URL manipulations in per-server context are really fast and efficient, per-directory rewrites are slow and inefficient due to this chicken and egg problem. But on the other hand this is the only way mod_rewrite can provide (locally restricted) URL manipulations to the average user.
En gros, le processus d'interprétation des URL recommence après le traitement du .htaccess. Donc, si tu transformes un .htm en .php, le traitement retourne au début, arrive au .htaccess, trouve un .php et colle le paramètre qui provoque un 404, d'où erreur systématique. Il faudrait ajouter une condition sur la réécriture des php, par exemple un test sur l'URL d'origine.
En revanche, ca marcherait en httpd.conf
 
WRInaute accro
oui d ou mon post plus haut qui ne marche effectivement pas. je ne connaissait pas ce fonctionnement du mod_rewrite. qu'est ce qu'on en apprend des tucs ici :)
 
Discussions similaires
Haut