путь маршрута рельсов не отображается в браузере (иногда) - PullRequest
0 голосов
/ 07 декабря 2010

После развертывания моего приложения rails 3 в рабочей среде я заметил, что пути не всегда отображаются в окне браузера.Например, при входе в систему или ссылках my_profile будет отображаться только http://my_app.com вместо ожидаемых http://my_app.com/login или http://my_app.com/my_profile. Представления изменились и работали.Я также мог видеть, что база данных была повреждена, и просмотры отображались из журналов (что привело меня к мысли, что это не простая проблема с кэшем браузера).Переход непосредственно к http://my_app.com/login сработал, однако использование ссылок в приложении привело бы меня к ожидаемому месту, оставив при этом отображаемый URL-адрес входа.Я попробовал это в нескольких браузерах (Firefox, Opera и Chrome) и получил то же самое поведение.Приложение было развернуто под nginx + passenger, а затем под nginx + thin cluster.У меня вопрос, что происходит?Это могут быть настройки nginx или настройки моей рабочей среды?Я не уверен, с чего начать.

Запуск curl -v my_app.com показывает

* About to connect() to my_app.com port 80 (#0)
* Trying xx.xx.xx.xx... connected
* Connected to my_app.com (xx.xx.xx.xx) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.21.1 (x86_64-apple-darwin10.4.0) libcurl/7.21.1 OpenSSL/1.0.0a zlib/1.2.5 libidn/1.19
> Host: my_app.com
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Set-Cookie: ARPT=PKKIKIS10.0.81.64CKILJ; path=/
< Content-Type: text/html; charset=utf-8
< Status: 200
< X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 2.2.5
< ETag: "fce6dec3543058bec16175466020a906"
< X-Runtime: 7
< Content-Length: 787
< Cache-Control: private, max-age=0, must-revalidate
< Server: nginx/0.7.62 + Phusion Passenger 2.2.4 (mod_rails/mod_rack)
< P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
< X-Cache: MISS from server.com
< Via: 1.0 server.com:8080
< Connection: close
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
<head>
<title>http://my_app.com/</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<meta name="generator" content="Hover Redirect Service">
</head>
<frameset framespacing="0" rows="100%,*" cols="100%" frameborder="no" border="0">
<frame name="DDIRECTXYZZY2" scrolling="auto" src="http://xxx.xx.xxx.xxx" noresize>
<frame name="DDIRECTXYZZY" scrolling="no" noresize>
<noframes>
<h1><a href="http://xxx.xx.xxx.xxx">http://my_app.com/</a></h1>
<p>Please <a href="http://xxx.xx.xxx.xxx">click here</a> to view the non-framed versi on.</p>
</noframes>
</frameset>
</html>

Так что это явно проблема.Все это обрамлено перенаправлением DNS?Настройка не Phusion Passenger + nginx.Это было изначально, но теперь его тонкий + nginx.Кроме того, при переходе непосредственно на IP-адрес приложения, все в порядке.При переходе на доменное имя я получаю оформленную версию.curl -v ответ только по ip-адресу также выглядит нормально (как при загрузке всей страницы).

Ответы [ 2 ]

1 голос
/ 07 декабря 2010

Проблема почти наверняка в ваших кадрах. Внутренний фрейм загружает правильный контент, но, поскольку вы (предположительно) не нацеливаете «top» в своих ссылках (или что бы то ни было), браузер по-прежнему отображает URL самого внешнего фрейма.

Рамки нацеливания: http://www.w3.org/TR/html4/present/frames.html#h-16.3

Если вы вообще не ожидали увидеть фреймы в своем ответе, то, скорее всего, они несут ответственность за некачественную службу «DNS». Получите реальный адрес DNS, указанный на вашем сервере, и вы будете петь.

0 голосов
/ 07 декабря 2010

Вы пытались использовать другой клиентский компьютер для проведения тестов? Если я последую вашему объяснению, это один из вариантов, который вы не исследовали.

Не могли бы вы прислать нам свою конфигурацию nginx?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...