Как сохранить семантику QueryString при преобразовании веб-сервера на базе MFC CHttpServer в ASP.Net?

Question

На устаревшем веб-сервере на базе MFC CHttpServer у нас есть примерно такая карта синтаксического анализа команд:

BEGIN_PARSE_MAP(MyHttpServer, CHttpServer)
    ON_PARSE_COMMAND(MyPage, MyHttpServer, ITS_I4 ITS_I4 ITS_I4 ITS_I4 ITS_PSTR ITS_PSTR ITS_PSTR ITS_I4)
    ON_PARSE_COMMAND_PARAMS("intParam1=11 intParam2=12 intParam3=13 intParam4=14 strParam5=s5 strParam6=s6 strParam7=s7 intParam8=18")
END_PARSE_MAP(MyHttpServer)

Это определяет страницу, доступную по адресу http://host/path/dllname.dll?MyPage который принимает до 8 параметров с именем intParam1, intParam2, intParam3, intParam4, strParam5, strParam6, strParam7, и intParam8.

Вызывающие приложения могут вызывать страницу с параметрами по имени следующим образом:

http://host/path/dllname.dll?MyPage?intParam4=32&strParam7=somestring

Но способ работы карт синтаксического анализа команд MFC заключается в том, что они также могут вызывать их с безымянными параметрами, если они предоставляются в порядке, определенном картой:

http://host/path/dllname.dll?MyPage?21&22&23&24&string5&string6&string7&28

Я хотел бы заменить этот старый код на АСП.Нет page, но у нас есть существующие вызывающие приложения, которые не будут изменены и которые вызывают страницу, используя оба стиля передачи параметров: именованный и безымянный.

Я могу легко управлять необходимым перезаписью URL-адреса, чтобы страница ASP.Net могла реагировать на URL-адрес, как указано выше, заменив путь/имя_dll.dll?Часть MyPage с путем к странице .aspx или обработчику .ashx.

Проблема возникает при попытке обработать безымянные параметры способом, эквивалентным старому анализатору параметров MFC.Request.QueryString обрабатывает все безымянные параметры как именованные с помощью нулевой и Request.QueryString[null] возвращает список значений, разделенных запятыми.Это довольно близко к работоспособному, но если один из параметров действительно содержит запятую, эта кодировка разваливается, потому что лишняя запятая не экранируется, и разделение строки на запятые приведет к слишком большому количеству параметров.

Я считаю, что в классическом ASP Request.QueryString(...) вернул коллекцию всех параметров с одинаковыми именами.Кажется, я не могу найти эквивалента этому в ASP.Net.

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

• Обработайте все параметры URL-адреса слева направо, используя & в качестве разделителя.
  • Если он назван (имеет знак равенства), примените значение к параметру с соответствующим именем, независимо от его положения.Если этому параметру уже присвоено значение, возникает ошибка.
  • Если параметр без имени, примените значение к параметру в n-й позиции в карте синтаксического анализа команд, где n — количество уже обработанных безымянных параметров плюс 1.Если этому параметру уже присвоено значение, произойдет ошибка.
• Применить значения по умолчанию из карты синтаксического анализа команд к любым параметрам, не назначенным выше.
• Если каким-либо параметрам из карты синтаксического анализа команд не присвоено значение, возникает ошибка.

Еще одно интересное замечание: оказывается, Request.QueryString.ToString() почти воссоздает исходные параметры URL-адреса, но всегда перемещает параметры с одинаковыми именами вместе, включая безымянные параметры, которые меня здесь интересуют.

Answer 1

я нашел это Request.QueryString имеет GetValues() метод.Это возвращает массив строк и решает проблему встраивания запятой в одно из значений.Это будет даже проще в использовании, чем разделение результатов Request.QueryString[null].

Мне еще предстоит немного поработать, чтобы использовать это для реализации сопоставления параметров URL-адреса в стиле MFC, которое обрабатывает как именованные, так и неименованные параметры.

Answer 2

Не уверен, что решит вашу проблему, но вы можете попробовать использовать Request.PathInfo.Это даст вам все, что введено после страницы, и затем вы сможете проанализировать его вручную, используя что-то вроде регулярного выражения.

Например, если у вас есть URL-адрес:

http://host/path/dllname.dll?MyPage?21&22&23&24&string5&string6&string7&28

Свойство Request.PathInfo вернет:

?MyPage?21&22&23&24&string5&string6&string7&28

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