Denton McLeod

набери при запущенном денвере в браузере http://localhost/Tests/ - там все для чего это надо описано. впрочем тестовые скрипты сделаны только для первой установки - если все работает как должно, денвер установлен верно, затем на это можно забить

в чем пишешь хтмл-код? если обычный блокнот, file -> save as, выбираешь тип All files, Encoding - ANSI. спросит переписать или нет - да

ну видимо файл в utf-8, а контент-тайп пишешь 1251 замени на

именно. на авастовском форуме поднималась такая тема. только там было печальнее - хостинг не народ, а новая почта. у них баннер ативирусу не нравится и вместо аватара аваст ругался

, если спящая память не подвела

а контекст какой? если ссылки основное содержимое страницы или хотя бы треть - одно дело, если "ссылки по теме" в конце - совсем другое

ой... java зло. имхо, конечно. иди на сайт Sun, у них много вкусностей по сабжу

мда...ты жесток

дабы не копипастить... http://sql.ru/forum/actualthread.aspx?bid=34&tid=517121&pg=1

ежели это будет основной формой (распространение каталога продукции на дисках), надо учитывать что слишком многие до сих пор используют ИЕ, где эти примочки вызовут желтый алерт-бар сверху и не будут работать пока человек не разрешит выполнение скриптов. а часть пользователей попросту испугаются странного диска, который может совершать нехорошие дествия, как их уверяет ИЕ. один из альтернативных вариантов - также клать на диск firefox portable и запускать его, но тогда возникнут проблемы с настройками лиски у тех пользователей, кто и так использует файрфокс. потому куда лучше, если есть возможность, заменить js на vbs

второе - свой сервер ставить надо. на джино можешь приехать в офис и попытаться лично договориться о прилинковке своей машины (хоть официально такой услуги и не предоставляется, если железяка в кластере может нормально работать, скорее всего пойдут навстречу). также на том же джино можешь завести еще один аккаунт (еще 14 гиг диска следовательно). на этом аккаунте потребуется подключить только поддержку php. далее на основном аккаунте создаешь два субдомена (download1.host.ru и download2.host.ru), второй переносишь на второй аккаунт. систему управления всем таким хозяйством написать будет не намного сложнее, чем для одного домена, просто потребуется сделать маленькое дополнение, которое будет выполнять аналогичные функции как на основном домене, но делать это с проверкой айпи, допуская только обращения скрипта с основного домена. пример: система управления (включая пользовательскую часть) на (1) логика фронтэнда (простейший вариант): получив запрос от пользователя, копируем нужный ему файл во временную директорию и даем прямую ссылку. по истечении часа файл удаляется. расширяем это на второй домен: там сидит скрипт, делающий такую же работу, но запросы ему идут от скрипта с первого домена. т.е. когда пользователь хочет скачать файл, скрипт проверяет на каком домене тот расположен, если на (2), обращается к скрипту (2), ожидает от него постоянной ссылки, затем отдает клиенту. скрипт на (2) проверяет только айпи с которого поступил запрос (этого будет достаточно при работе через сокет), т.к. у серверов джино адреса постоянные и вероятность что кто-то подберет АПИ скрипта на втором домене, захостившись при этом на том же сервере что и первый домен, крайне низкая.

очевидно что это надо для вывода data2... или вопрос был "зачем прописывать данные в содержимое ноды, когда можно их задавать атрибутом?" ответ - кому как удобнее

***DS скандирует: "Перл-спа-сет-мир! У-ра Уол-лу!" хотя для задачи создание сайта php более удобен, т.к. перл все же ныне универсальный язык и потому в некоторых местах громоздкий

ээ...... а каким образом это защищает от копирования собственно уже сгенерированного хэша? вообще принцип авторизации: пользователь вводит логин/пароль. эти данные (либо результат операций над ними в указанном примере) передаются на сервер. сервер сравнивает эти данные с имеющимися в списках доступа т.е. неважно зашифрованное передается или нет - можно перехватить сами передаваемые байты и соответственно тоже передать их. единственный (хоть и геморный способ) - шифруем при помощи какой-либо функции кроме логина/пароля также идентификатор собственно девайса, с которого осуществляется передача (тут можно испольовать айпи в комбинации с юзер-агентом или надежнее получить именно с готовым идентификатором системы, аналогично тому, как это делает майкрософт в активации win). тогда передается на сервер логин/пароль + зашифрованный хэш системного айди и айпишника + незашифрованный системный айди. сервер проводит такие же операции хэширования, в случае совпадения доступ разрешен. это не дает гарантии защиты от сдирания информации в процесе передачи - только лишь усложняет несанкционированный вход, т.к. гораздо сложнее подделать системный айди, для чего потребуется знание повыше чем "в институте паскаль проходили", но все равно взлом учетной записи вполне реален

> 50 символов > 100px /me записал в конвертер новую единицу измерения и коэффициент пересчета в пиксели