Обновите ArcaOS до уровня NeoWPS Установите набор PNG иконок, нарисованных дизайнером, специализирующемся на оформлении OS/2 Установите eSchemes 2018, чтобы менять цвета и кнопки на рабочем столе

TITLE: GoServe - WWW и Gopher сервер для OS/2

DATE: 2002-01-06 00:18:50

AUTHOR: Timur Kazimirov

GoServe - это многоцелевой сервер для OS/2, поддерживающий протоколы HTTP и Gopher. Сам сервер был создан в рамках программы EWS небезызвестным Mike Cowlishaw - создателем языков REXX, Object REXX и NetREXX. Целью создания GoServe было предоставить пользователям OS/2 возможность самим разворачивать на своих компьютерах серверы Internet, не вдаваясь в тонкости реализации протоколов передачи данных. Сама по себе процедура установки сервера является относительно быстрой и легкой.

Если протокол TCP/IP уже настроен, то GoServe можно настроить и запустить в работу буквально за несколько минут. Архив с GoServe включает в себя саму программу, инструкции по установке и запуску, рабочие примеры для WWW и Gopher.

Содержание:

• Принципы работы сервера
• Установка WWW-сервера
• Настройка GoServe
• Параметры запуска GoServe
• Другие фильтры для GoServe

Принципы работы сервера

GoServe, в отличие от других известных HTTP-серверов, является довольно оригинальной программой. Когда клиент запрашивает соединение, то программа читает запрос клиента и передает его без изменений фильтру. Фильтр - это обычная программа на языке REXX, которая обрабатывает запрос, совершает какие-либо действия и возвращает результат своей работы программе GoServe (это может быть специальная команда на отправку файла или сообщение об ошибке). Сервер, в свою очередь, передает все, что надо клиенту и закрывает соединение. Иными словами, GoServe служит 'посредником' между фильтром и клиентом. Использование фильтров на языке REXX придает серверу исключительную гибкость в работе - вы можете использовать как сложные фильтры с большим количеством возможностей, так и простые фильтры 'на одно действие' (если вам требуется высокая скорость). В комплект поставки GoServe входит пример такого фильтра, возможностей которого вполне достаточно для большинства непритязательных администраторов.

На каждый запрос создается отдельный тред для установки соединения, обработки запроса фильтром и ответа. GoServe берет на себя всю работу по формированию такого потока и управлению TCP/IP соединением, поэтому вам остается только модифицировать (при необходимости) фильтр и наполнять каталог данных информацией (документами, графикой и т.д.).

GoServe разработан для эффективной работы даже на дешевом оборудовании. Однако, по-умолчанию настройки предназначены скорее для большей безопасности, чем для высокой производительности. Для увеличения производительности и пропускной способности вам потребуется включить кэширование команды FAIL, уменьшить значение Connection maintenance и включить отложенный аудит (далее это будет рассмотрено более подробно). Чтобы GoServe работал быстрее, запускайте его минимизированным.

Установка WWW-сервера

Для работы вам потребуется последняя версия 2.52 пакета GoServe. Создайте на своем жестком диске каталог (например, C:\GoServe) и распакуйте в него следующие файлы:

• gofilter.80
• moveaud.cmd
• goserve.exe

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

Теперь создайте каталог, в котором будут храниться ваши HTML-документы, картинки и т.д. (например, C:\WWW). Вы можете взять за основу файлы из архива gohttp.zip. Стартовой страницей по умолчанию считается файл INDEX.HTM. Под стартовой страницей понимается файл в каталоге данных, который будет послан клиенту, если само имя ресурса не указано. Например, если клиент ввел в окне своего браузера http://www.yourdomain.ru, то ему будет послан файл C:\WWW\index.htm

Запустим GoServe командой GOSERVE HTTP, выберем меню Options, перейдем на закладку DataDir, введем C:\WWW и нажмем кнопку Apply (если имя каталога с данными указано неверно, то оно выделяется красным цветом).

Теперь, перейдем на закладку Filter. Здесь нужно указать имя файла программы-фильтра (в первый раз это будет GOFILTER.80). Эта программа должна находиться в том же каталоге, что и GOSERVE.EXE и иметь расширение, соответствующее номеру порта, на котором сервер 'слушает' (для WWW это, как правило, 80-й порт, а для Gopher - 70-й).

Вот, в принципе, и все - GoServe готов к работе! Теперь вы можете сообщить адрес своего компьютера друзьям (или недругам) и погрузиться в изучение HTML для создания красивых документов.

Настройка GoServe

Для настройки программы, выберите меню Options - откроется диалоговое окно настроек GoServe. В этом окне есть несколько страниц:

Страница Response показывает статистику по времени отклика и вы можете изменить график и цвета этой статистики.

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

• Параметр Show menu bar отвечает за показ полосы меню GoServe. Если его выключить, то к меню можно будет добраться щелкнув правой кнопкой мыши в окне программы.
• При включенном параметре Surface on startup окно GoServe будет автоматически минимизироваться при запуске. Я рекомендую включить этот пункт, чтобы GoServe работал быстрее.
• Включенный параметр Sounds on connections заставит GoServe 'блипать' динамиком при каждом запросе клиента. Из своего опыта скажу, что звук лучше выключить. В первое время забавно слышать 'блип', когда к серверу кто-то обращается, однако по прошествии времени, если ваш сервер довольно часто посещается, жизнь в офисе может стать невыносимой для окружающих... Да и на скорости работы программы это не отражается в лучшую сторону.
• А вот параметр File command cache рекомендую включить (Для каждого фильтра вопрос кэширования нужно обсуждать отдельно. Для фильтра, поставляемого с GoServe, включить кэширование можно), т.к. он отвечает за кэширование некоторых ответов сервера. Далее, мы более подробно обсудим его поведение.

На закладке Audit вы можете указать что и как GoServe будет записывать в лог-файл GOAUDIT.80 (создается в каталоге программы).

Я не буду подробно расписывать назначение каждого пункта - вы можете смело включить все. Если же все пункты выключены, то лог-файл создаваться не будет. Сразу оговорюсь - формат лог-файла GOAUDIT.80 абсолютно не похож на формат того же Apache и довольно мутен для понимания - в документации есть отдельная глава, посвященная его разбору. У меня, например, аудит GoServe отключен совсем, а логи ведутся фильтром. Если же вы все-таки используете аудит GoServe, то не забудьте включить параметр Lazy audit для ускорения работы.

А вот на страничке Limits я бы хотел разобрать все параметры поподробнее, потому что они довольно важны для производительности и безопасности сервера.

• Maximum at once - указывает сколько одновременно соединений (по умолчанию - 20) будет поддерживать сервер. Если максимум достигнут, то последующие соединения будут отвергаться. Учтите, что один клиентский запрос может породить несколько одновременных соединений - это зависит от настроек браузера клиента.
• Show warning at указывает процент одновременных соединений относительно вышеизложенного, после которого в окне появится красная полоска. Это своего рода предупреждение 'за мной сказали не занимать'.
• Open files per client указывает максимальное количество файлов, которые могут быть открыты в фильтре при обработке клиентского запроса (по умолчанию - 5 файлов). В случае простых фильтров, значение можно не изменять, однако для сложных, комплексных фильтров это значение, скорее всего, прийдется увеличить.
• End client after inactive - это период 'неактивности' клиента в секундах. Соединение с клиентом будет закрыто, если в течение этого времени никаких переданных или принятых данных от клиента не было. По умолчанию это 60 секунд, однако вы можете увеличить или уменьшить это значение в соответствии со своим опытом. Не исключено, что если среди посетителей вашего сервера есть много дайлапщиков, то это значение можно и увеличить. Однако не стоит забывать, что увеличение этого времени может привести к быстрому расходу допустимых одновременных соединений.
• End client after total - это период времени, после которого соединение с клиентом разрывается независимо от того - активен клиент или нет, передаются ли ему данные или нет. Это значение не может быть меньше периода 'неактивности' и, по умолчанию, равно 1200 секундам. Простое правило для расчета этого значения: это число секунд необходимое для передачи клиенту самого большого файла с вашего сервера в килобайтах (при условии, что средняя скорость передачи равна 1Кб/с). В случае медленного канала вы можете увеличить это значение в два или четыре раза.
• Connection maintain - 'период ожидания' в секундах. Определяет время, в течение которого GoServe будет ожидать новый запрос после ответа на запрос, в заголовке которого была фраза Connection: keep-alive. Заметьте, что разрыв такого соединения считается нормальным поведением и не регистрируется как ошибочное превышение лимита.
  По умолчанию этот параметр равен нулю, что означает, что GoServe никогда не будет обрабатывать больше одного запроса на соединение. Однако вам, скорее всего, прийдется увеличить это значение. Рекомендуется указать 10-15 секунд для обработки запросов к страницам, содержащим графику или 60-120 секунд для запросов к многостраничным документам.
  
• Wait for TCP/IP start определяет время, в течение которого GoServe будет при запуске ждать пока не поднимется стэк TCP/IP. Этот параметр (по умолчанию 600 секунд) имеет смысловое значение в случае, если ваш сервер имеет дайлап-доступ в Интернет.
• Header size указывает максимальный размер (в тысячах байт) заголовка запроса от клиента. Если размер заголовка превысит это значение, то транзакция будет отвергнута. По умолчанию, максимальный размер заголовка равен 10 тысячам байт.
• Body data size определяет максимальный размер (в тысячах байт) клиентского запроса. Если размер запроса превышает это значение, то транзакция будет отвергнута. По умолчанию этот параметр равен 50 тысячам байт.

Параметры запуска GoServe

Все свои настройки GoServe хранит в файле GOSERVE.INI, который создается в каталоге программы. При желании, вы можете изменить их в командной строке запуска. GoServe принимает следующие параметры:

• HTTP - указывает GoServe стартовать в режиме HTTP-сервера.
• GOPHER - указывает GoServe стартовать в режиме Gopher-сервера.
• PORT number - указывает GoServe "слушать" указанный порт. Это может быть полезным при отладке или виртуальном хостинге. Например, команда GOSERVE HTTP PORT 8080 запустит GoServe в режиме HTTP-сервера, который будет 'слушать' порт с номером 8080 вместо стандартного 80-го порта.
• FILTER filtername - указывает GoServe использовать программу filtername вместо указанной в настройках. Например, команда GOSERVE HTTP FILTER SRELITE.80 приведет к тому, что GoServe будет использовать фильтр SRELITE.80 вместо указанного в настройках. Учтите, что полного имени файла использовать нельзя - фильтр должен находиться в том же каталоге, что и GOSERVE.EXE.
• DATADIR directory_name - заставляет GoServe использовать именно этот каталог данных. В строке directory_name вы можете не указывать завершающий слэш ("/") - он будет добавлен автоматически. Пример: GOSERVE HTTP DATADIR C:\OTHER_WWW
• QUIETFAIL - сообщает GoServe, что при ошибке в фильтре GoServe должен 'тихо скончаться', не выводя при этом никаких диагностических диалоговых окон. Этот параметр очень полезен, когда вы запускаете свой сервер в режиме автопилота.
• Есть еще ряд параметров командной строки, однако их описание я здесь не привожу - все это подробно изложено в оригинальной документации.

Применение параметров командной строки очень полезно при отладке, запуске нескольких экземпляров программы для различных нужд и т.д.

Другие фильтры для GoServe

Программ-фильтров для GoServe разработано довольно много. Наиболее мощным в настоящее время является фильтр Дэниела Хеллерштейна - SRE-http. Один только размер архива последней версии превышает полтора мегабайта! Я настоятельно рекомендую, после того как вы разберетесь с GoServe, установить этот пакет и пользоваться им. Он представляет из себя полноценный HTTP 1.1 сервер с огромным количеством возможностей, во многом не уступает, а даже превосходит другие известные HTTP-серверы для OS/2.

Если вам не требуется такой 'навороченный' сервер, вы не занимаетесь виртуальным хостингом, требования к управлению доступом у вас довольно умеренные, нововведениями HTTP 1.1 вы не пользуетесь, а вас интересует только скорость, то обратите внимание на фильтр SRE-Lite (автор тот же).

Прекрасным примером фильтра, разработанного под свои нужды, является Interdart Goserve Web Filter. Помимо того, что он обеспечивает стандартные HTTP-сервисы, в нем реализован малоизвестный интерфейс SIBOM (Simple Interface Business Objects Messaging) той же фирмы.

Предыдущие фильтры во многом заимствовали идеи и части кода из фильтра GoHTTP, написанного очень хорошим человеком Доном Мейером.

Очень оригинальным фильтром, выполняющим узкоспециализированную задачу, является фильтр из комплекта поставки POP3 сервера OS2PopS (созданного опять-таки в рамках программы EWS). Очень многие его игнорируют по одной простой причине - в документации не сказано, что для его работы требуется GoServe и вообще не сказано как его запускать. И такое бывает...

Автор статьи: Timur Kazimirov

Первая публикация: http://ns.rnlease.snc.ru/~timur/os2/gsrv.shtml

Редактор: Eugene Gorbunoff

Комментарии:

Сергей 2002-01-08 04:08:34	Нифига себе! И давно в оси такой сервер есть??
Сергей 2002-01-08 04:39:34	А на других платформах такой сервер существует? Или он затонет вместе с осью?
Timur Kazimirov 2002-01-08 05:12:27	Есть он года эдак с 1994-го, если не раньше. Бета-версия под винду также в наличии. Ну а REXX под винду также давно есть.
Sergey Posokhov 2002-01-08 13:05:32	А можно ли с помощью фильтров добиться выполнения PHP под осью? Если да - пиши продолжение статьи :-)
Deniska 2002-01-08 16:37:52	по секрету скажу, что есть альфа версия PHP-мода для IBM HTTP Server. (PHP-emx для Apache-emx есть уже очень давно)
Timur Kazimirov 2002-01-09 02:11:10	To: Sergey Posokhov PHP легко можно использовать в любом фильтре с поддержкой CGI. Сразу оговорюсь, что поставляемый с GoServe фильтр CGI не поддерживает, однако SRE-http, SRE-Lite, GoHTTP вполне можно настроить для работы с PHP. Что же касается использования не-CGI (что явно предпочтительнее), то можно сделать REXX-callable версию PHP.DLL и использовать ее в SRE-http по полной программе.
Eugene Gorbunoff 2002-01-09 03:25:33	Кто уже читал эту статью - обратите внимание, в конце появилось дополнение - автор прислал 3 абзаца про доп.фильтры.
Василий А. Сидоров 2002-01-09 04:57:03	Предупреждение пользующим ORexx. Каждый вызов фильтра оставляет незакрытые семафоры (багофича ORexx'а:(), а в результате, после примерно 8064-й транзакции будет либо диалоговое окошко об ошибке в RexxStart(), либо трап системы. Я видел и то и другое.
Timur Kazimirov 2002-01-09 07:27:32	To: Василий А. Сидоров Это для любого фильтра или для какого-то определенного? Сам по себе GoServe семафоры для фильтра вроде бы не создает. Что же касается самих фильтров, то тут уж кто как написал :). Дэниел, в свое время, даже спец.версию своего Sre-http для ORexx'а выпустил, но поддержку ее уже прекратил.
Sergey Posokhov 2002-01-09 12:42:34	Это все потому что HTTP серверы - "системы с накоплением ошибок". Есть даже книжки про них. Такая система - как динозавр в болоте: вытащил одну лапу - завязла другая. Все семафоры и т. п. привязаны к определенному приложению, PID или EXE, и пока оно не сломается, они не будут закрыты. Пока динозавр не утонет в болоте. Один из примеров - JSP (Resin, Tomcat, JServ и прочие). В свое время я натрахался с этим JSP, и вот почему: программу начинали делать до меня, на JSP она выглядит как макароны в тарелке - видно только хвосты. Где что сломалось понять невозможно, чтение Log'ов помогало, но не очень - причину ошибки было сложно установить. Где и когда кто-то "не закрыл" семафор, файл или SQL Statement, в логах не сообщалось :-) Все это разваливалось на глазах. Два часа работает и рушится. Никогда раньше такого не видел. Может, можно сделать так: написать отдельный Application Server, например, на Watcom VX-REXX, чтобы он обращался к СУБД, вел Log и т. п. и делает всю работу. Ведь это не так сложно. К нему сделать оболочку под GoServe, отдельно, которая будет общаться с ним через Named Pipes и XML, посылать запросы серверу и выдавать HTML страницы пользователю. Оболочку можно и на CGI сделать - тормозов не будет. Получим многоуровневую систему: СУБД-AppServer-GoServe (PHP или даже CGI) или AppServer-LogAnalyzer или вообще СУБД-AppServer-ЧтоНибудьТекстовое (для слежения за системой через Telnet). Кто-нибудь делал такие проги? Если да - поделитесь полезным опытом.
Timur Kazimirov 2002-01-10 02:44:04	To: Sergey Posokhov Обрати внимание на фильтр SRE-http. Там можно такие фишки делать. Можно, разумеется, подобный фильтр и с нуля написать, и он , скорее всего, будет работать быстрее и надежнее, однако... Для затравки: <HTML> <BODY> <!-- interpret code тут идет текст программы на REXX'е любой сложности. разделитель строк - точка с запятой, вместо SAY использовать QUEUE, EXIT не использовать. Где такое можно сделать? :) --> </BODY> </HTML>
Sergey Posokhov 2002-01-10 13:24:17	Так можно сделать на PHP в Apache и на Rexx в NetData. Вопрос не в этом. А в том, как отделить код для создания страниц HTML от всей остальной программы. И сделать не с помощью объектов на языке Java или PHP 4.x - это уже все пройдено, получаются те же макароны, только завязанные в узлы. А сделать многоуровневое приложение, у которого есть ядро и внешние сервисы - если это вообще возможно... Такая телега может состоять из: 1. СУБД - например, DB2, с вьюхами и хранимыми процедурами; 2. AppServer - например, на VX-REXX или на чем-то еще, можно на Яве, только чтобы работало быстро; 3. Протокол обмена данными - например, с помощью XML и Named Pipes; 4. Оболочки для создания страниц HTML - с помощью Apache/PHP или GoServe/REXX; 5. LogAnalyzer, текстовые отладчики - по желанию. Самое непонятное здесь - часть третья. Невозможность сделать ее легко и просто заставляет нас строить системы на движках вроде Resin и Tomcat (это JSP, она же "condom technology"). А затем бороться с глюками. Я и сейчас пишу на JSP. Только уже другую систмеу. Все хорошо, пока заказчик не начал ее использовать. Как только начнет - она опять развалится. И почему люди ведутся на слово "Ява", как будто это заклинание, которое спасет мир :-)
Sergey Posokhov 2002-01-10 13:36:32	Далее. Как правило, ломаться будет Часть Вторая из приведенного выше списка. Она всегда ломается, так и должно быть. Но ее надо просто разделить на несколько независимых частей. Получим два десятка AppServer'ов, которые будут работать одновременно. Что с того, если OS/2 - многозадачная система. Зато они не будут влиять друг на друга. Когда пишешь под JSP, все запросы обслуживает только ОДНА Ява-машина. Которая постоянно набирает ошибки и рано или поздно разрушается вместе со всеми данными сразу ВСЕХ пользователей. Потому JSP так и называют... не я это придумал. У меня вопрос - кто-нибудь строил такие многоуровневые системы? Как их делают? На чем? Как обеспечить многозадачность внутри каждого AppServer'а? И так далее.
Василий А. Сидоров 2002-01-10 16:14:22	2Тимур Казимиров Это проблема не фильтра RexxStart(), которым его зовут. GoServ (мною) использовался как максимально простой способ воспроизведения бага.
Timur Kazimirov 2002-01-11 08:36:28	To: Sergey Posokhov Что касается DB2 - я не советчик. Я с ней дела не имел. С Oracle - да, кое что было примерно подобное, но не 3-х уровневое, как ты пишешь. Давай списываться - глядишь, сообща, вместе решение и найдем удовлетворительное
Timur Kazimirov 2002-01-11 08:40:33	To: Василий А. Сидоров Очень интересно! Я, в свое время, так на OREXX и не смог переключиться аккурат, похоже, из-за этого. MFC ответа четкого на проблему так и не дал :((
Timur Kazimirov 2002-01-11 08:44:20	Я тут скоро (надеюсь) выкину статью про SRE-http. Может быть многие вопросы/проблемы разрешатся сами собой? Просто сомнения взяли - а это надо обществу?
Sergey Posokhov 2002-01-11 13:20:04	Кто о чем, а я все о том же :-) Если запустить несколько HTTP-серверов и заставить их слушать разные порты TCP/IP, получится примерно то же, что я хочу получить. Одна часть системы будет работать, например, по адресу myhost:8080, другая - по адресу myhost:1234 и так далее. При падении-зависании одной части системы все остальные будут продолжать отвечать на запросы пользователя. Если GoServe и SRE-http позволяет строить такие системы - напиши об этом. Такая статья будет полезна. Пока я знаю только, как этого добиться в PHP - запустить десяток Апачей. Однако Апачи из-за использования fork() плодятся с невероятной скоростью, как кролики. Поэтому GoServe может быть лучше, хе-хе...
Sergey Posokhov 2002-01-11 13:38:30	Задача сводится к следующему: предположим (умозрительно), что некая СУБД разрешает каждому Приложению держать не более... мммм.... десяти открытых Соединений с собой. Предположим, что СУБД следит за значениями PID этих самых Приложений. Доля истины в этом есть. Дальше, пусть одно из Приложений не закрывает Соединения по вторникам и четвергам в 14-00 и ломается в это время через десять минут работы, зависая в ExitList-е, как это делал мой любимый Resin :-) Так вот, хотелось бы: написать систему, состоящую из нескольких HTTP-серверов (или SRE-http - ???), каждый из которых выполнен в виде отдельного Приложения и имеет свой PID, чтобы во вторник и четверг во время перерыва на обед большая часть системы продолжала все-таки работать!! Это можно сделать с помощью CGI, когда на каждый запрос создается отдельное Приложение, то есть вызывается Perl.exe, но если есть еще решения - пишите! Потому что я их не знаю :-(
Timur Kazimirov 2002-01-14 02:51:33	To: Sergey Posokhov Так это же легко. Причем для любого, практически, фильтра. Накопируй их с расширениями, соответствующими номерам портов и сделай CMD-шник вида: GOSERVE HTTP PORT 80 FILTER MYFILTER.80 DATADIR C:\WWW80 GOSERVE HTTP PORT 81 FILTER MYFILTER.81 DATADIR C:\WWW81 GOSERVE HTTP PORT 8080 FILTER MYFILTER.8080 DATADIR C:\WWW8080 и т.д. Каталоги данных можно одинаковыми сделать. Каждый GOSERVE будет иметь свой PID. Тут другой вопрос - как отметил Василий Сидоров, в случае ORexx'а может сама REXX-подсистема слететь.
Gleb Mazursky 2002-01-14 13:05:04	Сергей, зачем так "охульно огаивать" Java/JSP ? То что ты рассказал при динозавра и проч. действительно встречается в проектах, которые начали делать с нуля "нулевые" люди. А если бы ты поучаствовал предварительно в нормальных проектах, где есть чему поучиться, то ты бы так не отзывался. Java - это Ultimate Tech для Server-Side! Надо просто использовать JSP для того, для чего она создана - для content presentaion. И отдельно позаботиться об отладке. И инкапсулировать логику в объектную модель, а не "расклеивать лапшу"....
Gleb Mazursky 2002-01-14 13:54:12	to Sergey Posokhov: еще хочу прокомментировать: >> Когда пишешь под JSP, все запросы обслуживает только ОДНА Ява-машина. Которая постоянно набирает ошибки и рано или поздно разрушается вместе со >> 1. У меня ничего не рушится *;) 2. Если ты не в курсе, можно настроить обработку каждой сессии в индивидуальной JVM. Это умеет Resin & Oracle AppServer. Может и Tomcat умеет, но не уверен. >> всеми данными сразу ВСЕХ пользователей. >> а то уж как напишешь... про сериализацию сессий слыхал?
klan 2002-01-14 15:27:15	Hi, All/2! Мне не совсем понятно зачем все это? Как я понял продукт последний раз обновлялся в 1998 году... это без коментариев. Далее - если необходимо быстро и просто организовать веб-сервер - существует web/2 ([url]), который поддерживает rexx, если я не ошибаюсь... Я уже не говорю о существовании Russian Apache/2, который подымается совсем не долго, даже если Вы не представляете, что собственно надо!!! Тогда чем это лучше??? Где соль?!?!? Bye!
Timur Kazimirov 2002-01-15 02:19:28	To: klan Что касается вопроса "зачем", то однозначного ответа я дать, конечно, не могу. Может быть просто потому, что мне это интересно :) то же касается Web/2, Apache и пр., то не только у них есть поддержка REXX, но... Но в виде CGI, а это не всегда бывает приемлемым. А то что GoServe не обновлялся с 1998 года безусловно является недостатком, но только в одной области - отсутствие встроенной поддержки HTTP/1.1 в области кэширования и разговора с прокси-серверами, однако это обходится очень и очень просто - запретом кэширования команды FILE и перекладыванием всей работы на фильтр (что, например, сделано в фильтрах SRE-Lite и SRE-http). К слову сказать, SRE-http обновлялся последний раз 2 января этого года :) А вот чем это все лучше... Я, честно говоря, не ставил своей задачей показать - какой это крутой, по сравнению с другими серверами, софт. Я просто рассказал о нём :) А вот "где соль" я сказать могу - GoServe сам по себе не делает ничего - все делают фильтры, написанные на REXX'е, то есть логика обработки запросов вынесена отдельно.
Timur Kazimirov 2002-01-15 11:14:52	В дополнение - тот же Дэниел в настоящее время делает "заменитель" GoServe - [url] пока, правда, у него не все получается, но кто знает, что там будет дальше.По крайней мере, говорить о том, что версия от 5 января - устаревшая, не стоит :)
Timur Kazimirov 2002-01-23 09:32:02	Тут, надеюсь, скоро ещё одна статья "в продолжение темы" выйдет. Про SRE-http. Сама статья вряд ли будет большой - типа обзора и быстрой установки, а вот за переводом документации прошу ко мне, если кто заинтересован

Прокомментируйте эту статью (напоминаем, автор работал над текстом несколько недель, уважайте мнение других).

Ваше имя: Ваш E-Mail: CODE:
Ваш комментарий:

eComStation - реактивная система, удобная для работы. Вытесняющая многозадачность + поддержка многопроцессорности с 1994 года + Большинство программ используют многопоточность.