 |
| [Cheyenne] Serveur centralisé de fichiers .r | |
| trigram | 17-Jan-2011/17:29:07+1:00 |
| Je travaille sur mon projet avec les workers et je suis passé à la phase d'avoir un cheyenne qui centralise les scripts .r Alors j'essaie de faire : >> worker-list: load http://localhost/worker/worker-list.r connecting to: localhost ** User Error: Error. Target url: http://localhost/worker/worker-list.r could not be retrieved. Server response : HTTP/1.1 503 Service... ** Near: worker-list: load http://localhost/worker/worker-list.r Et si je fais http://localhost/worker/worker-list.r j'ai bien soit le contenu du fichier soit le téléchargement qui se déclenche... Comprend pas tout. Need help ! | |
| DocKimbel | 17-Jan-2011/17:38:57+1:00 |
1) Dans le fichier de config par défaut de Cheyenne, il y a: bind-extern RSP to [.j .rsp .r] Il faut retirer le .r de la liste sinon les scripts REBOL en .r seront évalués côté server. 2) Le code "503 Service..." n'est pas une signature Cheyenne (Cheyenne utilise le message "Out of Resources" pour le code 503). Conclusion: tu as un serveur autre que Cheyenne qui tourne en port 80... | |
| trigram | 17-Jan-2011/17:53:33+1:00 |
| @DocKimbel 1) Effectivement, j'avais vu cette config, donc j'avais mis en commentaires la ligne, j'ai retiré le .r Effectivement, il m'affiche le résultat lorsqu'il y a le .r dans la config. Si je l'enlève, il me propose le téléchargement du fichier. 2) Je ne comprends pas, car si j'arrête le service Cheyenne (je suis sous WinXP Pro), je n'arrive plus à accéder à la ressource via un browser... je relance Cheyenne avec la config... avec le changement de config, dans mon browser il me propose le téléchargement du fichier mais dans REBOL e même message d'erreur... | |
| DocKimbel | 17-Jan-2011/18:14:55+1:00 |
| Fait un `netstat -nba` en ligne de commande, et regarde quel programme occupe le port 80. Si tu as Skype ou Yahoo Messenger installé, ils peuvent occuper le port 80 sans prévenir. Si tu lances Cheyenne en écoute sur un port déjà occupé, le serveur sera instable, voire la plupart du temps, ne répondra pas du tout. Essaye de lancer Cheyenne sur un port innoccupé pour vérifier que c'est un problème de conflit de port, soit en utilisant -p 12345 par exemple, soit en ajoutant dans la section [global] du fichier de config, la ligne suivante: listen 12345. Autres pistes: - essaye de lancer Cheyenne en mode normal et non en mode service. - utilise les logs verbeux pour voir ce qui se passe côté Cheyenne (par exemple: cheyenne.exe -vvv) | |
| trigram | 17-Jan-2011/21:52:43+1:00 |
| J'ai tester sur une machine pro mais en dehors du réseau sur laquelle je viens de mettre juste cheyenne.exe Cela fonctionne. Par contre, sur les autres machines, c'était sur le réseau pro et un mix de cheyenne.exe avec le source pour avoir les applications exemples... J'avais essayé le netstat -nba, mais il n'y avait que cheyenne sur le port 80. J'ai essayé avec 12345, pareil même type d'erreur... Bizarre, je referai une série de test demain. | |
| trigram | 17-Jan-2011/22:17:19+1:00 |
| En fait, j'ai parlé trop vite. Cela ne fonctionne pas : ni sur le port 80 ni sur le port 12345 par exemple. Toujours la même erreur : >> print read http://localhost:12345/ connecting to: localhost ** User Error: Error. Target url: http://localhost:12345/ could not be retrieved. Server re sponse: HTTP/1.1 503 Service Unavailable ** Near: print read http://localhost:12345/ | |
| trigram | 17-Jan-2011/22:37:37+1:00 |
Bon, attention, pas taper svp...  Erreur de débutant : pb du proxy ! Dans le user.r, il faut mettre : system/schemes/default/proxy/bypass: [localhost 127.0.0.1] C'est vraiment pas cool que ce ne soit pas par défaut ! Pb résolu donc. Merci Doc. | |
| trigram | 17-Jan-2011/23:10:16+1:00 |
| Je me suis réjoui un peu trop vite. Rebol communique avec Cheyenne mais il fait une erreur 404. Dans les logs en mode -vvv, j'ai des :
17/1-23:05:49.109-[uniserve] Calling >on-received< with "GET http://127.0.0.1/worker-list.r HTTP/1.0^M^/"
17/1-23:05:49.125-[HTTPd] ================== NEW REQUEST ==================
17/1-23:05:49.125-[HTTPd] Request Line=>GET http://127.0.0.1/worker-list.r HTTP/1.0
17/1-23:05:49.125-[HTTPd] Trying phase method-support ( mod-static )
17/1-23:05:49.140-[HTTPd] Trying phase url-translate ( mod-static )
17/1-23:05:49.140-[HTTPd] => request processed
17/1-23:05:49.140-[uniserve] Calling >on-received< with {^M
Accept: */*^M
Connection: close^M
User-Agent: REBO}
17/1-23:05:49.156-[HTTPd] Request Headers=>
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.8.3.1
Host: 127.0.0.1
Proxy-Authorization: removed by GreG
Donc, globalement, avec la config proxy et le bypass il communique avec cheyenne mais j'ai un 404 quoi que je fasse. Si j'enlève le proxy, ca marche. | |
| DocKimbel | 17-Jan-2011/23:53:33+1:00 |
| Le bypass n'a pas l'air de fonctionner, dans le log, la requête est de type "proxy", il est normal que Cheyenne réponde 404 dans ce cas. | |
| trigram | 18-Jan-2011/0:29:08+1:00 |
| Effectivement, mais il y a qqchose que je ne comprends pas : je suis avec le proxy, si j'enlève le bypass, j'ai l'erreur du début et dans REBOL il n'arrive pas à communiquer avec cheyenne, cela me parait logique puisqu'il demande au proxy une ressource locale, si je mets le bypass, je communique avec cheyenne mais j'ai une erreur 404, je ne trouve pas cela logique puisqu'il arrive jusque cheyenne et c'est cheyenne qui renvoi le 404... qu'est-que cette ligne avec Proxy... implique pour cheyenne ? | |
| DocKimbel | 18-Jan-2011/11:17:28+1:00 |
| 1) Comme indiqué dans mon message précédent, Cheyenne réagit normalement (un code 5xx en retour aurait été plus approprié sans doute), le problème vient du client HTTP REBOL et de sa non-prise en compte du bypass. Pour être plus clair, en examinant le code du scheme HTTP, on peut voir dans la fonction 'open que proxy/bypass n'est jamais testé, en conséquence, le bypass ne marche jamais avec le client HTTP natif, c'est un bug de REBOL. Voici un correctif rapide à placer en début de script ou dans %user.r : ;-- Functions extracted from HTTP scheme to be exposed in global context find-bypass: func [host bypass /local x] [ if found? host [ foreach item bypass [ if any [ all [x: find/match/any host item tail? x] ] [return true] ] ] false ] in-bypass: func [host bypass /local item x] [ if any [none? bypass empty? bypass] [return false] if not tuple? load host [host: form system/words/read join dns:// host] either find-bypass host bypass [ true ] [ host: system/words/read join dns:// host find-bypass host bypass ] ] ;-- Fix for ignored bypass in HTTP handler use [sshh ctx patch][ sshh: system/schemes/http/handler ctx: second get in sshh 'open bind patch: [not in-bypass port/host port/proxy/bypass] first find ctx 'build-port append select ctx 'all patch ] En utilisant la config de test suivante dans la console: system/schemes/http/proxy/bypass: [localhost 127.0.0.1] system/schemes/default/proxy/host: "proxy.com" system/schemes/default/proxy/type: 'generic J'obtiens:
>> read http://yahoo.fr
connecting to: yahoo.fr
** Access Error: Cannot connect to proxy.com
** Where: open-proto
** Near: read http://yahoo.fr
>> read http://127.0.0.1
connecting to: 127.0.0.1
== {<html>
<head>
^-<title>Welcome!</title>
</head>
<body>
<img src="logo.png">
<center>
<h2>Congratulations, you are running Cheye...
Après l'application du patch correctif, le bypass est maintenant bien pris en compte par le client HTTP. | |
| DocKimbel | 18-Jan-2011/11:19:14+1:00 |
| 2) Ton identifiant et mot de passe sont exposés dans le log que tu as publié (facilement décodable dans le Proxy-Authorization), il est temps d'en changer... | |
| trigram | 18-Jan-2011/18:03:03+1:00 |
| 1) OK, tout cela fonctionne désormais. Tu m'enverras la facture Doc Je dépose l'incident sur RAMBO ? 2) J'ai changé et GreG a supprimé l'entrée. Merci. | |
| DocKimbel | 18-Jan-2011/18:21:03+1:00 |
| Oui, ça vaut le coup de faire un ticket RAMBO sur ce bug et proposer le correctif suivant : 1) in prot-root.r: move 'find-bypass and 'in-bypass functions from 'open-proto context to root-protocol context (or net-utils object). 2) in prot-http.r: replace the following line:
generic-proxy?: all [port/proxy/type = 'generic not none? port/proxy/host]
by
generic-proxy?: all [
port/proxy/type = 'generic
not none? port/proxy/host
not root-protocol/in-bypass port/host port/proxy/bypass
]
| |
| trigram | 19-Jan-2011/0:19:30+1:00 |
| RAMBO submitted. | |
|
Login required to Post. | |