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

На устаревшем веб-сервере на основе 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

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

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

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

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

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

  • Process all parameters in the URL from left to right, using & as separator.
    • If named (has an equal sign), apply the value to the parameter with the corresponding name, regardless of its position. If that parameter already assigned a value, error.
    • Если безымянный, примените значение к параметру на n-й позиции в карте синтаксического анализа команд, где n — количество уже обработанных безымянных параметров плюс 1. Если этому параметру уже было присвоено значение, ошибка.
  • Применить значения по умолчанию из карты синтаксического анализа команд к любым параметрам, не назначенным выше.
  • Если каким-либо параметрам из карты синтаксического анализа команды не присвоено значение, ошибка.

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


asp.net query-string mfc
person GBegen    schedule 18.09.2009    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Не уверен, что решит вашу проблему, но вы можете попробовать использовать 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

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

person Mun    schedule 18.09.2009
comment
Я попробовал свойство Request.PathInfo, и оно получает только часть после страницы и до, но не включая?. Если я собираюсь анализировать это самостоятельно, я думаю, мне нужно использовать свойство Request.Url.Query. - person GBegen; 18.09.2009

arrow_upward
0
arrow_downward

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

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

person GBegen    schedule 18.09.2009