Как исправить Rebol Cheyenne 404 с помощью доменного имени и файла конфигурации? - PullRequest
0 голосов
/ 16 июня 2011

На Windows Server 2008 я создал

reboltutorial.com [
    root-dir %/www/
    default [%index.html %index.rsp %index.php]
]   

Возвращает страницу ошибки 404, не найденную. Шайенн работает только с IP-адресом (http://88.191.118.45:2011/ в порядке http://reboltutorial.com в порядке, но на ISS 7). Как это исправить?

Обновление: журнал ошибок

 Error in [conf-parser] : Can't access file www/ws-apps/ws-test-app.r 
 Error in [conf-parser] : Can't access file www/ws-apps/chat.r !

Ответы [ 2 ]

2 голосов
/ 08 декабря 2011

Вы должны убедиться, что у вас есть каталог с именем www на карте, в которую вы установили cheyenne. (По умолчанию dir %www/).

После этого убедитесь, что отсутствующие файлы www/ws-apps/ws-test-app.r и www/ws-apps/chat.r также существуют.

1 голос
/ 24 июня 2011

Прежде всего, HTTP 1.1 отправляет полный URL-адрес по сеансу TCP (включая имя домена, введенное в строке Location:). Таким образом, один IP-адрес может обслуживать несколько доменов (Apache называет это VirtualHosts), поэтому при просмотре по IP-адресу будет отправляться другой URL-адрес любому веб-серверу, получившему запрос.

Таким образом, не является большой технической загадкой, чтобы ваша машина была настроена таким образом, чтобы она обслуживала другую страницу для IP-адреса и домена. Но так как вы добавили "reboltutorial.com" в конфигурацию Cheyenne, кажется, что - если что-нибудь - , что будет работать, в то время как версия IP-адреса будет давать сбой.

Я не запускаю Cheyenne, и вы не предложили более подробную информацию о вашей конфигурации. Но так как никто не ответил, я посмотрел на дерево исходных текстов, чтобы дать несколько советов о том, что вы можете попробовать.

Мы знаем, что Шайенн получает запрос и принимает решение вернуть 404 из-за формата ошибки. Апач один выглядит иначе:

http://reboltutorial.com/show-me-apache-404/

http://88.191.118.45:2011/show-me-cheyenne-404/

Значит, Шайенн получает запрос. Это то, что мы знаем. Решение об обслуживании 404 принимается в send-response в файле HTTPd.r . Это довольно простой тест:

if all [file? out/content not exists? out/content][
    log/error ["File not found: " mold out/content]
    out/code: 404
    out/content: none
]

Если это место, где генерируется ваш 404, то в вашем журнале должен быть «Файл не найден:» и упоминание того, что это за файл. Если нет, то происходит что-то странное. Вы можете что-то добавить туда (даже quit, если вы подозрительно относитесь к распечатке), просто чтобы убедиться, что он доходит до линии.

(К вашему сведению: в будущем, когда вы смотрите на другие проблемы с шайеннами, есть параметр под названием «многословие», который влияет на вывод, и вы можете увидеть в при получении в HTTPd .r файл , что при многословности> 0 будет регистрироваться при получении запроса:

if verbose > 0 [
    log/info ["================== NEW REQUEST =================="]
    log/info ["Request Line=>" trim/tail to-string data]
]

Если вы повысите уровень детализации, вы можете довольно быстро найти указание на проблему. Если нет, код достаточно читабелен, и вы можете добавить свои собственные точки трассировки. )

...