Есть программа-сервер, решено что удаленно ею управлять надо будет с помощью обыкновенного браузера. Соответственно, надо писать свой WEB-сервер.

Можно написать вручную обработку HTTP-запросов - опыт есть, но дело в том что в дальнейшем наверное нужно сделать какую-нибудь шифрацию данных. Что умеет браузер в этом направлении? Я знаю только про SSL, если HTTP-ответы вручную оформлять - насколько сложно потом будет прикрутить SSL?

Как вообще SSL работает? При запросе какую информацию браузер посылает? Внутри запроса есть некая информация типа открытого ключа, которым надо шифровать ответ?

Можно ли SSL без сертификатов использовать, то есть только для шифрации данных, когда все дело вообще происходит внутри интранет сети без выхода в интернет?

Есть еще варинты HTTP-шифрации кроме SSL?

cgi/php/asp.net для кого придумали?

каждый занимается свои делом
- ставится нормальный веб сервер,
- прикручивается SSL сертификат,
- пишется прослойка, которая принимает запросы от веб сервера и управляет программой

Что такое "управлять программой-сервером"? Старт/стоп/..? Зачем тут шифрование?

LMD, RTFM

TidTCPServer или TidHTTPServer + SSL
Обработка постов и гетов ничем не будет отличаться. Что с ссл, что без нее.

- пишется прослойка, которая принимает запросы от веб сервера и управляет программой

Гы.
Значит дополнительно к имеющемуся приложению-серверу ставим веб сервер, пишем некую прослойку, после чего учим свой сервер понимать и реагировать на прослойку.

гениально.
А чо так мало звеньев-то?
:)

> Гы.
> Значит дополнительно к имеющемуся приложению-серверу ставим
> веб сервер, пишем некую прослойку, после чего учим свой
> сервер понимать и реагировать на прослойку.
>
> гениально.
> А чо так мало звеньев-то?
> :)

какой вопрос - такой ответ :)
не озвучено ни что за программа, ни какая среда обитания всего этого зоопарка
поэтому, предложен самый экономически обоснованный ответ - прослойку (cgi/php/asp) всяко проще писать, чем реализовать весь веб сервер, да еще и с SSl-ями
не так ли?

большинство постов даже комментить не охота, видимо пятница кое-кто уже принял неплохо ;)

Reindeer Moss Eater ©   (11.04.08 19:49) [4]
TidTCPServer или TidHTTPServer + SSL

дык а что ты имеешь в виду под "+SSL"? В том и дело, что я не знаю как навесить на HTTP-трафик SSL-шифрацию. Плохо представляю что такое SSL, да и если честно не очень хотелось бы разбираться. Надежный бы и простой способ - вот что мне нужно.

SSL каким-то образом внедряется в HTTP-заголовки? Или SSL можно ЛЮБОЕ TCP-соединение шифровать? Есть может функция какая, чтобы ей на вход байтики нешифрованные, а на выходе получить шифрованные уже? Какой-то пароль использовать при этом? Я просто не в курсе, куда бы побыстрее посмотреть.

Reindeer Moss Eater ©   (11.04.08 19:51) [5]
А чо так мало звеньев-то?

я тож об этом подумал ;)

прослойка нужна другая - между стулом и клавиатурой. ;)

> прослойка нужна другая - между стулом и клавиатурой. ;)

между метлой и асфальтом :)

PS
Пятница. Уже принял. Неплохо.

предложен самый экономически обоснованный ответ - прослойку (cgi/php/asp) всяко проще писать, чем реализовать весь веб сервер, да еще и с SSl-ями
не так ли?

<Цитата>

Разумеется не так. Считаем:
в моем случае:
- протокол не изобретаем, используем малое подмножество фич http 1.0
- реализуем в (одном месте) прием и разбор заголовков запросов и отправку ответов.

в твоем:
- разрабатываем протокол взаимодействия между приложением и прокладкой.
- пишем его реализацию (в двух местах)
- стыкуем прокладку со сторонним http сервером.
- ставим и настраиваем сам сторонний сервер

Дальше продолжать?

кстати, с чего вдруг нам потребовалось реализовывать "весь веб сервер" ?

Я бы вообще сказал, что уже существующему серверу добавлятся возможность взаимодействия посредством http протокола. Только и всего.

> Дальше продолжать?

лёгка

> в моем случае:
> - протокол не изобретаем, используем малое подмножество
> фич http 1.0
прикручиваем веб-сервер к программе серверу

> - реализуем в (одном месте) прием и разбор заголовков запросов
> и отправку ответов.
+ прикручиваем SSL движок, отлаживаем (мне уже здесь страшно)

достаточно просто, если у нас для этого есть квалифицированный разработчик, время которого стоит дорого

также, далеко неясны затраты на сопровождение и расширение

> в твоем:
> - разрабатываем протокол взаимодействия между приложением
> и прокладкой.
это да, нужно поработать

> - пишем его реализацию (в двух местах)
1 место - управляемая апликация
2 место - собственно разработка "прокладки"

> - стыкуем прокладку со сторонним http сервером.
20 минут работы разработчика среднего и ниже среднего уровня
либо работа местного админа

> - ставим и настраиваем сам сторонний сервер
от 5 минут до нескольких часов - зависит от сервера и того, кто ставит
либо сервер уже стоит

здесь затраты на сопровождение меньше, так как пхп/перл/асп разработчика найти проще
также, решение легче расширить, так как не нужно лезть в код сервера
с другой стороны - решение будет работать медленней, факт

в опщем, можно долго спорить, какие помидоры лучше ;)

-- ушел пить пиво

[пьет пиво]
XML XML XML

Реализуеш XML передачу, а там уже хоть шифрую хоть в рог бараний скручивай,
кстати не совсем понял чем веб клинт отличается от тяжелого клиента?
И тот и другой в конечном счете передают запросы в нормальном виде серверу, который на них реагирует. В чем отличае тяжелого, от легкого клиента? Тяжелый может обработывать свою логику в ответ на полученные данные.

достаточно просто, если у нас для этого есть квалифицированный разработчик, время которого стоит дорого

ой не смеши.
ридлн в цикле и парсинг строки это квалификация?

а придумывание своего протокола и его реализация даже дворнику под силу типа?  Или приложение с прокладкой будут обмениваться прямой мыслепердачей?

здесь затраты на сопровождение меньше, так как пхп/перл/асп разработчика найти проще

Ой, мама! Кроме тех ненужных звеньев что уже перечислены еще и админа апача потребуется искать?

Может стоит поставить вопрос более по другому?
Есть клиент тяжелый который постоянно опрашивает что то, надо прикрутить легкий клиент, который через сервак сразу отправлял задания тяжелому клиенту?

+ прикручиваем SSL движок, отлаживаем (мне уже здесь страшно)

положить в папку две дллки и выставить три-четыре паблишед свойства в инспекторе объектов? Страшно?
:))))

написал ответ
подумал
вытер

спорить не о чем - нам ничего не известно ни об инфраструктуре, ни о сервере, ни о чем
так, пустой треп

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

это не считая апача и его водителя.

Reindeer Moss Eater ©   (11.04.08 23:10) [18]
Вы не могли бы раcкритиковать мой вариант с двумя сервисами тяжелым и легким?

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

Reindeer Moss Eater ©   (11.04.08 23:18) [20]
Легкий клиент отправляет запросы на сервер, которые после обработки(примение логики сервера) отправляются тяжелому клиенту, который реагирует полученные данные. Критика важна для меня в целях найти свои ошибки.

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

Reindeer Moss Eater ©   (11.04.08 22:58) [16]
положить в папку две дллки и выставить три-четыре паблишед свойства в инспекторе объектов? Страшно?

можно поподробнее? А то я спрашивал в [7] ...

а вообще спасибо за флуд народ ;)))