Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет dibr ([info]dibr)
@ 2008-11-15 01:52:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
google chrome
     Гугл хром на моем компьютере только что нарушил принцип причинности. Нормально показавши страничку http://ftp.startrekftp.ru, но на ftp://ftp.startrekftp.ru устойчиво заявляя "DNS error - cannot find server". При том, что ftp://ftp.startrekftp.ru, как показывает проверка из независимого браузера, существует и откликается на 21 порту (только анонимусов пускать перестал, а регистрация на http://ftp.startrekftp.ru уже который день сломана).

     А нарушается именно принцип причинности потому, что DNS-запрос (а именно ошибку DNS выдает хром) делается на доменный адрес а не на URL, то есть не содержит ftp:// или http://, делается этот запрос до попытки коннекта, поэтому "ошибка DNS" не может зависеть от того, к ftp или к http ресурсу хочет обратиться браузер - это на момент выдачи запроса просто-напросто неизвестно никому кроме браузера :-)

     Чтобы не нарушать полноты информации сообщу, что браузеры у меня ходят через прокси, что хром не имеет собственных настроек прокси и использует настройки MSIE, что в настройках стоит галка "один прокси для всех протоколов" (т.е. ftp ходит over http), и что MSIE честно выдаёт последовательность "401 FTP Server requires authentication \ This FTP server rejects anonymous access \ 530 Login incorrect". Из этого следует, в частности, что фраза "DNS error" является типичным случаем так называемого вранья - DNS недоступен через http-прокси, значит и "DNS error" тут быть не может, может быть только слишком вольная интерпретация ругани прокси-сервера.

     "И так у них всё!" :-))) Хотя за исключением нескольких "мелочей" хромом я весьма доволен - как основной браузер он вполне справляется. Как единственный, правда, не справляется однозначно...


(Добавить комментарий)


[info]crazy_blu@lj
2008-11-15 11:42 (ссылка)
Совершенно аналогичную ситуацию наблюдал в IE
Просишь адрес - для ускорения тебе показывают то, что из сохранившегося кэша, а паралельно делается запрос. Если HTTP вернет что все неизмнно - ОК. Если нет - перерисует. Если недоступен - нарисует после нормально нарисованной страницы "ну не смогла я" :)

(Ответить) (Ветвь дискуссии)


[info]dibr@lj
2008-11-15 17:43 (ссылка)
У ёперы когда-то (сейчас видимо исправили, во всяком случае я давно не наблюдал) был забавный глюк. При нажатии на reload происходило внешне(!) совершенно нормальное обновление страницы - с появлением текста, перезагрузкой стилей (и соответствующим быстрым изменением того, что на экране)... но при этом (как показывали логи прокси) на собственно страничку не делался даже get-запрос (никакой, ни просто get, ни if-modified-since, ни ещё какой-нибудь - ну то есть сама страничка тупо и молча бралась из кеша), зато аккуратно перезапрашивалась вся обвязка типа файлов css и картинок.

А у msie чаще натыкался на другое. Грузится у него страница грузится, уже половина загрузилась (и отрисована)... и тут опа! Коннекшн ресет бай пир - что-нибудь где-нибудь рухнуло.
И уже отрисованная половина странички исчезает, а вместо неё появляется стандартное эксплорерное нечто с ошибкой. Причем страничка реально была реально загружена реально наполовину - у неё можно было даже посмотреть (наполовину загруженный) page source :-)

(Ответить) (Уровень выше)


[info]tesanoff@lj
2008-11-16 04:47 (ссылка)
использовал бы ты FF и не знал бы горя. :-)

(Ответить)