Como posso preservar a semântica QueryString ao converter um servidor web baseado MFC CHttpServer para ASP.Net?

Question

Em um servidor web baseado legado MFC CHttpServer, temos um mapa de análise de comando algo como isto:

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)

Isto define uma página acessível em http://host/path/dllname.dll?MyPage que aceita até 8 parâmetros nomeados intParam1, intParam2, intParam3, intParam4, strParam5, strParam6, strParam7 e intParam8.

Os aplicativos que chamam podem chamar a página com os parâmetros de uma forma chamado assim:

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

Mas a maneira MFC comando de análise mapeia trabalho, eles também podem chamá-lo com parâmetros sem nome, desde que eles são fornecidos na ordem definida pelo mapa:

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

Gostaria de substituir este código antigo com um ASP.Net página, mas temos existente chamar os aplicativos que não serão alterados que chamar a página usando ambos os estilos de passagem de parâmetros, com o nome e sem nome .

I podem facilmente gerenciar o URL necessário reescrever para permitir que uma página ASP.Net para responder à URL como dado acima, substituindo o path / dllname.dll ? MyPage parte com o caminho para uma página .aspx ou manipulador .ashx.

O problema surge quando se tenta lidar com os parâmetros sem nome em uma forma equivalente ao antigo analisador parâmetro MFC. Request.QueryString trata todos os parâmetros sem nome como sendo nomeado com nulo e Request.QueryString[null] retorna uma lista separada por vírgulas dos valores. Isso é muito perto de viável, mas deve um dos parâmetros realmente conter uma vírgula, essa codificação desmorona porque a vírgula extra não é escapado e dividir a string nas vírgulas vai acabar com muitos parâmetros.

No ASP clássico, acredito Request.QueryString(...) retornou uma coleção de todos os parâmetros que foram com nomes idênticos. Não parece haver nenhum equivalente a isso em ASP.Net que eu possa encontrar.

Como uma questão secundária, o mapa de comando de análise MFC teve alguma lógica muito complicada para lidar com uma mistura de parâmetros nomeados e não nomeados. Embora os chamadores da página em questão não estará misturando seu uso desta forma, eu estou interessado em talvez duplicar a lógica para sermos mais completos. Alguém pode confirmar que o comportamento do MFC foi essencialmente o seguinte?

• processar todos os parâmetros na URL da esquerda para a direita, usando & como separador.
  • Se o nome (tem um sinal de igual), aplique o valor para o parâmetro com o nome correspondente, independentemente de sua posição. Se esse parâmetro já atribuído um valor, erro.
  • Se não identificado, aplique o valor para o parâmetro na posição enésima no mapa de comando de análise, onde n é o número de parâmetros sem nome já processados ??mais 1. Se esse parâmetro já foi atribuído um valor, erro.
• Aplicar valores padrão de mapa de análise de comando para quaisquer parâmetros não atribuídos acima
• Se algum parâmetro de comando parsing mapa não tenham sido atribuído um valor, erro.

Uma nota mais interessante, parece que Request.QueryString.ToString() será quase reconstituir os parâmetros originais no URL, mas sempre se move os parâmetros com nomes idênticos para estar juntos, incluindo os parâmetros sem nome Estou preocupado com aqui.

Answer 1

Descobri que Request.QueryString tem um método GetValues(). Isso retorna uma matriz de cadeias e resolve o problema de uma vírgula ser incorporado dentro de um dos valores. Vai ser ainda mais fácil de usar do que ter que dividir os resultados de Request.QueryString[null].

Eu ainda tenho um pouco de trabalho para usar isso para implementar um MFC-como mapeamento de parâmetros de URL que lida com ambos nomeados e parâmetros sem nome.

Answer 2

Não tenho certeza se resolve o seu problema, mas você pode tentar usar Request.PathInfo. Isto lhe dará tudo entrou após a página, que você pode, em seguida, analisar manualmente usando algo como um regex.

Por exemplo, se você tivesse a URL:

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

A propriedade Request.PathInfo voltaria:

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

Processamento isso em um conjunto de valores que você pode trabalhar com também poderia ser problemático, pois você tem ambos os parâmetros chamado un-nomeados e, mas isso deve ser alcançado usando expressões regulares e / ou dividir a string.