Vers un code HTTP 451 pour signaler un blocage judiciaire ?

Une très bonne idée qui ne verra malheureusement à mon avis jamais le jour...

Si le but véritable de projet de lois comme LOPPSI était vraiment de censurer les sites des Pedo-Nazi ça se saurait :/

C'est surtout un bon prétexte pour pouvoir museler internet...

"Il s'agit très certainement d'un hasard" : cf Appendix A. Acknowledgements, "Thanks also to Ray Bradbury."

Je suppose qu'il est délivré par Apache mod_censor ?

/dev/tty, le 13/06/2012 - 16:32

Je suppose qu'il est délivré par Apache mod_censor ?

Question intéressante : qui renverras le code d'erreur ? Le serveur où est hébergé le site ?
Cela voudrait dire que soit il est bloqué partout, soit il faut une géoloc avec tout l'aléatoire que ça implique.

Bref je vois mal comment un serveur pourrait anticiper un comportement qui va se déclencher ou non dans les tuyaux entre lui et le client.

J'ai d'abord trouvé l'idée intéressante... Mais au final ça "avalise" le filtrage...

(edit : toujours ces problèmes d'UTF-8 dans les commentaires, impossible d'écrire le caractère "points de suspension")

Pourquoi avoir choisi 451 ?

j'aurais choisi plutôt 419, référence en hommage au scam nigérien

451 deja pris

http://technet.micro...=exchg.80).aspx

fyr, le 13/06/2012 - 17:45

451 deja pris

http://technet.micro...=exchg.80).aspx

C'est pas une erreur native de http mais propre à exhange, rien à voir... Et osef des ces horreurs micrsoftiennes.

Ca me dit tjrs pas comment le serveur va deviner qu'il est filtré en aval...

Si le serveur est bloqué, il risque pas d'envoyer un code d'erreur.
Du coup, cette proposition reviens a demander si en plus de bloquer un site, les instances judiciaires doivent détourner son traffic vers leur propres serveurs ?

Pourquoi un code en 4** ? La section 10.4 de la RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4) prévoit bien que les codes d'erreur en 4** sont destinés aux erreurs côté client.

Je rejoins tass_ sur l'entité émettrice d'une telle page d'erreur.

tass_, le 13/06/2012 - 17:51

C'est pas une erreur native de http mais propre à exhange, rien à voir... Et osef des ces horreurs micrsoftiennes.

Ca me dit tjrs pas comment le serveur va deviner qu'il est filtré en aval...

Il ne le devine pas forcément :
"This status code indicates that the server is subject to legal restrictions which prevent it servicing the request.
Since such restrictions typically apply to all operators in a legal jurisdiction, the server in question may or may not be an origin server"
http://www.tbray.org...ted-status.html

Baltyre, le 13/06/2012 - 18:14

Si le serveur est bloqué, il risque pas d'envoyer un code d'erreur.
Du coup, cette proposition reviens a demander si en plus de bloquer un site, les instances judiciaires doivent détourner son traffic vers leur propres serveurs ?

C'est ce qu'ils font deja assez souvent. Le "FBI Warning" n'est pas uniquement sur les DVD.
L'avantage ici serait d'avoir un code d'erreur normalise, avec ou sans page d'erreur personnalisee, ce qui permet un traitement informatique.
C'est simplement une proposition pour ameliorer la transparence, pas les comportements.

milord, le 13/06/2012 - 18:41

Il ne le devine pas forcément :
"This status code indicates that the server is subject to legal restrictions which prevent it servicing the request.
Since such restrictions typically apply to all operators in a legal jurisdiction, the server in question may or may not be an origin server"
http://www.tbray.org...ted-status.html

wormlore, le 13/06/2012 - 18:41

C'est ce qu'ils font deja assez souvent. Le "FBI Warning" n'est pas uniquement sur les DVD.
L'avantage ici serait d'avoir un code d'erreur normalise, avec ou sans page d'erreur personnalisee, ce qui permet un traitement informatique.
C'est simplement une proposition pour ameliorer la transparence, pas les comportements.

Quoi ??? Un code d'erreur http envoyé non pas par le serveur d'origine mais par un entité au milieu ?
Beurk, ça ne normalise rien, n'ajoute aucune transparence, et question traitement informatique, bof. Qu'on ai un code d'erreur HTTP ou une page (normalisée pour le FBI) venant d'une autre entité, on peut le savoir pareil.

C'est juste affreux, une erreur HTTP non envoyée par le serveur émetteur, beurk.

Je vomis et je reviens.

tass_, le 13/06/2012 - 18:54

milord, le 13/06/2012 - 18:41

Il ne le devine pas forcément :
"This status code indicates that the server is subject to legal restrictions which prevent it servicing the request.
Since such restrictions typically apply to all operators in a legal jurisdiction, the server in question may or may not be an origin server"
http://www.tbray.org...ted-status.html

wormlore, le 13/06/2012 - 18:41

C'est ce qu'ils font deja assez souvent. Le "FBI Warning" n'est pas uniquement sur les DVD.
L'avantage ici serait d'avoir un code d'erreur normalise, avec ou sans page d'erreur personnalisee, ce qui permet un traitement informatique.
C'est simplement une proposition pour ameliorer la transparence, pas les comportements.

Quoi ??? Un code d'erreur http envoyé non pas par le serveur d'origine mais par un entité au milieu ?
Beurk, ça ne normalise rien, n'ajoute aucune transparence, et question traitement informatique, bof. Qu'on ai un code d'erreur HTTP ou une page (normalisée pour le FBI) venant d'une autre entité, on peut le savoir pareil.

C'est juste affreux, une erreur HTTP non envoyée par le serveur émetteur, beurk.

Je vomis et je reviens.

Pourquoi ça ne normalise rien ?
Et non, un code d'erreur HTTP ce n'est pas la même chose qu'une simple page (qui renvoie une 200 ou une 302).
Ne pas oublier qu'un serveur web, ça ne sert pas le contenu uniquement aux navigateurs (web services, tout ça).

Vous avez oublié de préciser que le Tim Bray là, il bosse chez Google.

tass_, le 13/06/2012 - 18:54

Quoi ??? Un code d'erreur http envoyé non pas par le serveur d'origine mais par un entité au milieu ?
Beurk, ça ne normalise rien, n'ajoute aucune transparence, et question traitement informatique, bof. Qu'on ai un code d'erreur HTTP ou une page (normalisée pour le FBI) venant d'une autre entité, on peut le savoir pareil.

C'est juste affreux, une erreur HTTP non envoyée par le serveur émetteur, beurk.

Je vomis et je reviens.

Jamais entendu parlé des proxy et/ou caches HTTP ? (voire des reverse proxys, bien plus courants). Ca fait partie d'HTTP/1.1 (cf http://www.ietf.org/rfc/rfc2068.txt). Cela dit, renvoyer un code d'erreur quelqueconque n'empêche pas d'ajouter des informations supplémentaires (ce qu'ils appellent le message "personnalisé"). Et je trouve qu'un message qui dit "l'accès est site machintruc.com a été bloqué sur décision judiciaire" est bien plus transparent qu'une erreur DNS...

Accessoirement, je soupçonne Google de vouloir utiliser ce code pour "purger" leur moteur (voire leur cache) des liens pointants vers des sites bloqués, ce qui leur simplifierait sans doute la tâche, puisqu'il semble que ce soit une demande connexe au blocage DNS d'un site.

Adirelle, le 13/06/2012 - 20:16

Accessoirement, je soupçonne Google de vouloir utiliser ce code pour "purger" leur moteur (voire leur cache) des liens pointants vers des sites bloqués, ce qui leur simplifierait sans doute la tâche, puisqu'il semble que ce soit une demande connexe au blocage DNS d'un site.

Plus que pour "purger" je les verrais plutôt l'utiliser pour décider d'aller le crawl depuis une autre adresse qui ne serait pas bloquée

Parce qu'à l'heure actuelle où ça renvoie une erreur DNS ou dans certains cas une 404, ce sont des situations où Google les purge automatiquement. Et l'intérêt pour eux (Google) serait justement de ne pas purger de leur index des ressources qui existent juste parce qu'elles sont bloquées depuis l'endroit où se situe le robot qui a essayé d'atteindre la page, sachant que Google a des robots distribués à travers le monde (bon pour le DNS, vu qu'ils utilisent leur propre DNS, faudrait que ce soit bloqué au niveau des serveurs racines par contre pour que ça les impacte )

Y'a pas que le HTTP dans la vie !
Et le courriel, le FTP, la messagerie instantanée ?

Le 451 est d'ailleurs déjà pris pour le SMTP : "Requested action aborted: local error in processing".
db

Adirelle, le 13/06/2012 - 20:12

tass_, le 13/06/2012 - 18:54

Quoi ??? Un code d'erreur http envoyé non pas par le serveur d'origine mais par un entité au milieu ?
Beurk, ça ne normalise rien, n'ajoute aucune transparence, et question traitement informatique, bof. Qu'on ai un code d'erreur HTTP ou une page (normalisée pour le FBI) venant d'une autre entité, on peut le savoir pareil.

C'est juste affreux, une erreur HTTP non envoyée par le serveur émetteur, beurk.

Je vomis et je reviens.

Jamais entendu parlé des proxy et/ou caches HTTP ? (voire des reverse proxys, bien plus courants). Ca fait partie d'HTTP/1.1 (cf http://www.ietf.org/rfc/rfc2068.txt). Cela dit, renvoyer un code d'erreur quelqueconque n'empêche pas d'ajouter des informations supplémentaires (ce qu'ils appellent le message "personnalisé"). Et je trouve qu'un message qui dit "l'accès est site machintruc.com a été bloqué sur décision judiciaire" est bien plus transparent qu'une erreur DNS...

Lorsqu'on est sur Internet (le vrai pas celui d'un opérateur de téléphonie mobile hein ?) il n'y a RIEN entre soi et le serveur.
Aucun intermédiaire ne peut donc injecter quoi que ce soit dans l'intervalle.
Si ce code nécessite pour chaque hébergeur d'introduire un reverse-proxy afin de servir l'ensemble de ses sites hébergés (plusieurs milliers voire plusieurs dizaines de milliers) le coût va s'en ressentir sur le tarif de location à moins d'en faire un principe discrétionnaire.
db

milord, le 13/06/2012 - 19:38

Pourquoi ça ne normalise rien ?
Et non, un code d'erreur HTTP ce n'est pas la même chose qu'une simple page (qui renvoie une 200 ou une 302).
Ne pas oublier qu'un serveur web, ça ne sert pas le contenu uniquement aux navigateurs (web services, tout ça).

Ca "normalise" si tu veux, mais le fait qu'un man in the middle (ici le FAI ou une agence gouvernementale type FBI) envoit un code d'erreur à la place du serveur, désolé c'est tout sauf une bonne pratique.

Adirelle, le 13/06/2012 - 20:12

Jamais entendu parlé des proxy et/ou caches HTTP ? (voire des reverse proxys, bien plus courants). Ca fait partie d'HTTP/1.1 (cf http://www.ietf.org/rfc/rfc2068.txt).

Sans blague ? Comme si t'allais m'apprendre mon boulot.
Ca n'a rien à voir avec le cas présent. Dans le cas présent une entité tierce au client (ou à la DSI derrière le client qui a mis en place les caches et/ou proxies... ou tout ce que toute entité liée au client qui a voulu mettre ) et au serveur (ou toutes ses réplications, load balancing, caches CDN ou tout ce que tu veux que l'entité responsable du serveur ait voulu mettre entre) se permet d'envoyer un code d'erreur.
Que cette entité par une volonté de censure ait voulu rediriger le trafic allant vers le serveur vers une page expliquant cette censure est déjà assez malsain, alors si en plus on lui permet de répondre une erreur HTTP normalisée à la place du serveur ça devient carrément obscène. Le prochain pas sera de lui laisser renvoyer des erreur 404 à la place du contenu non voulu ?

milord, le 13/06/2012 - 19:38

Cela dit, renvoyer un code d'erreur quelqueconque n'empêche pas d'ajouter des informations supplémentaires (ce qu'ils appellent le message "personnalisé"). Et je trouve qu'un message qui dit "l'accès est site machintruc.com a été bloqué sur décision judiciaire" est bien plus transparent qu'une erreur DNS...

Déjà fait, cf la jolie page du FBI quand ils saisissent un domaine. Le blocage par DNS n'est qu'un artifice temporaire qui ne sert à rien tout le monde le sait.