Раз так, то зачем ему html?
Я недавно работал в фирме, где занимался писательством конфигуратора для некоего устройства на MODBUS'е. Причём для разных таких устройств (модулей) пишется свой конфигуратор. Это долгая и нужная однообразная работа. Самое что неприятное, все конфигураторы практически одинаковые, отличаются только набором настраиваемых регистров MODBUS'а, а это ведёт за собой разный вид пользовательского интерфейса. Можно было бы написать один движок на все случаи жизни (ну на многие), а для каждого устройства программер бы писал отдельную мелкую dll, которая использует возможности универсальной проги.
Мы тут пришли к идее некоего интерпретатора, чтобы упростить работу по клепанию настройщиков девайсов.

Так вот, я думаю, автору неохота заниматься писательством отдельных настройщиков, т.к. это целый проект и каждый раз новый. Так до старости можно их клепать. Мне показалось, что он хочет использовать IE как своего рода интерпретатор пользовательского интерфейса, благоразумно желая применить современный стиль конфигурирования - красивый HTML интерфейс.
При этом, ни его железяка, ни RS485 пока для таких новшевств вроде бы не применяются. Кроме того, девайсы уже готовые и встаивать туда Линукс мягко говоря никто не будет.

Вот я и предложил ему, если уж так охота, отделаться малой кровью. Все его подпрограммки работы с девайсом остаются прежние. Изменяется только форма заполнения (представления) параметров. Уж не знаю какая там была ранее. В девайсе он должен хранить просто код интерфейса с формой, где поля формы именованы, это input'ы. Приложение верхнего уровня просто должно возвращать список с элементами типа параметр-значение. Не нужно никакого сервера. Броузер - такой же компонент, как ListBox и не более того, тока покрасивше.

Таким образом, при подключении посылаем запрос на конфигурацию прибору, тот возвращает HTML контент с формой. Наше универсальное приложение верхнего уровня отображает HTML контент (считайте это просто скрипт, сценарий) и ждёт от пользователя ввод и нажатие Submit. После того как пользователь нажал Submit, наше универсальное приложение формирует список типа параметр-значение от пользователя и передаёт его устройству также как и делало это ранее.
Устройство то ранее как-то конфигурировалось ведь? Мы ничего не изменили, только возможно представление параметров конфигурации. Даже про метод GET знать ничего не нужно.

Можно пойти дальше, если параметров действительно сотни. Сделать навигацию. Тогда устройство должно поддерживать методы по блочной передаче параметров, либо что-нить мутить со скриптами и передавать сразу все параметры, короче помозговать можно. Зато будет стильно и красиво, а главное не понятно и как же это без IP адреса конфигуратор общяется по RS485 с устройством :) гы

От такие мои мысли и соображения. Очень просто. Никакого мудрежа со стандартными протоколами.