Системному администратору на заметку. В больших компаниях иногда требуется изменить настройки локального прокси-сервера. Но что делать, чтобы после этого не потребовалось оббежать все компьютеры для изменения настроек? Тут на помощь админу приходит протокол Web Proxy Autodiscovery Protocol (WPAD).
Есть два способа сообщить информацию о локальном прокси-сервере: через DHCP и через DNS. По соображениям максимальной совместимости, предпочтительно использовать DNS.
Для этого необходимо занести запись, указывающую на домен "wpad" с работающим web-сервером. В корень web-сервера необходимо поместить файл с именем "wpad.dat". Этот файл представляет собой JavaScript, содержащий функцию "FindProxyForURL". Этот файл будет автоматически затребован и выполнен web-браузерами на всех компьютерах локальной сети. Содержание файла может быть примерно следующим:
function FindProxyForURL(url, host)
{
if (isPlainHostName(host) ||
dnsDomainIs(host, "my.local.network.domain.org") ||
(host=="127.0.0.1") )
return "DIRECT";
else
return "PROXY my.proxy.server.address:8080";
}
Из примера понятно, что браузер попробует определить к какому адресу пытается подключиться, в случае локальной сети использует настройки без прокси, иначе будет задействован прокси my.proxy.server.address:8080.
По материалам журнала Linux Journal.
UPD В настройках браузеров все же должно быть включено автоматическое определение прокси. Opera не поддерживает WPAD.
На самом деле, первое что приходит в голову. Если ожидается частое, изменение прокси, то на каждом компе иметь демон, который слушает определенный порт. В случае изменения посылать, широковещательное сообщение по локальной сети. Демон должен будет изменить сам все настройки.
Что делать, если браузеры --- не браузеры, а нечто подобное (wget), и про WPAD никогда не узнают?
Ну, не использовать "нечто подобное (wget)" в корпоративной среде.
Идея с демоном хорошая, но я бы ее расширил. Не только для прокси. Сервис может с некоторой периодичностью проверять наличие на web-сервере в локальной сети, например, xml-файла с настройками и при необходимости вносить изменения. Или даже лучше не xml, а тот же JavaScript, который можно потом выполнять на движке, например, V8. Во!
Похоже начал изобретать велосипед. :) Такое, наверное, давно есть.
ОМГ. Они программу в честь механизма назвали.
http://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29
Никогда не понимал, зачем нужен серверный JS.
Названия других движков JS не менее интригующие. Взять хотя бы SpiderMonkey. :)
К Monkey в английском языке вообще заметна нездоровая любовь. Я до сих пор (кхе, кхе, как дипломированный лингвист)) ) не знаю как перевести на русский Code Monkey. Быдлокодер? Вроде не то.
Ну, я бы перевел как "веселый программер". :) Даже Лингво выдает кучу значений слова monkey, в английском monkey используется в куче идиом, причем смысл этого слова становится совсем далеким от обезьян. Да и в русском, например, выражение "мартышкин труд" не обязательно означает эксплуатацию обезьян. :)
Ну как же, например, для этого. И не обязательно на серверах использовать. Можно просто в свою прогу вставить, чтобы предоставить юзеру возможность писать дополнения. Имхо, архиполезная вещь эти JS-движки.
С colubrid тоже красиво.
Про серверный javascript прочитал несколько статей. Но не понимаю зачем? C такbм же успехом можно использовать licp, ocaml, erlang на стороне сервера или какой-нибудь интерпретатор (?) C++. Это все забавно. Но смысла я пока не вижу.
Ну, если люди пользуются, значит находят для себя что-то полезное. :) Но одна причина лежит на поверхности — web-программисту не требуется учить новый язык.
Да, но это все языки, а node.js — библиотека. Подозреваю, что некоторым кажется, что она сильно упрощает асинхронное программирование в web.
Хочу понять для себя, в каком случае действительно стоит ее использовать. Про переключение контекстов --- новый язык, тут согласен. Но иногда оно бывает полезно.
Про N юзверей могу привести свой диалог:
A: Предлагаю использовать Pascal. Он более надежен и более высокоуровневый.
В: Но для таких вещей большинство использует C++, значит он, наверно, лучше.
A: Если в нашей стране Алкоголиков больше, чем Академиков, совсем не означает, что быть Алкоголиком лучше.
Хотя такой диалог могли мне привести и Вы, если бы я отстаивал "правильность" привычных для web языков.
Ну, сами разработчики говорят, что node.js нужно использовать тогда, когда предполагается
высокая нагрузка. Оно, в принципе, так. Для того же PHP для каждого запроса каждый раз выполняется сценарий. Здесь запускается один сценарий, параллельно обрабатывает запрос, но программа не прекращает работу, а засыпает, пробуждаясь при новом запросе через механизм колбэков. В принципе, такая идея имеет право на существование.
Node's goal is to provide an easy way to build scalable network programs. In the "hello world" web server example above, many client connections can be handled concurrently. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation.
С википедии:
Интересно, что они курили, когда писали IE6?
Ну, как известно, небольшие модификации общепринятых стандартов — одно из главных конкурентных преимуществ MS. :)