È stato rilevato un valore Request.Path potenzialmente pericoloso dal client (*)

Ricevo l'errore piuttosto autoesplicativo:

Un valore Request.Path potenzialmente pericoloso è stato rilevato dal client (*).

Il problema è dovuto *all'URL della richiesta:

https://stackoverflow.com/Search/test*/0/1/10/1

Questo URL viene utilizzato per popolare una pagina di ricerca in cui "test *" è il termine di ricerca e il resto dell'URL si riferisce a vari altri filtri.

C'è un modo semplice per consentire questi caratteri speciali nell'URL? Ho provato a modificare il web.config, inutilmente.

Devo codificare / decodificare manualmente i caratteri speciali? O c'è una buona pratica per fare questo, vorrei evitare di usare stringhe di query. - ma potrebbe essere un'opzione.

L'applicazione stessa è c# asp.netun'applicazione di moduli web che utilizza il routing per produrre il simpatico URL sopra.

Il *carattere non è consentito nel percorso dell'URL, ma non vi sono problemi nell'utilizzarlo nella stringa di query:

http://localhost:3286/Search/?q=test*

Non è un problema di codifica, il *personaggio non ha un significato speciale in un URL, quindi non importa se l'URL lo codifica o meno. Dovresti codificarlo utilizzando uno schema diverso, quindi decodificarlo.

Ad esempio, usando un carattere arbitrario come carattere di escape:

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

E decodifica:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

Se stai usando .NET 4.0 dovresti essere in grado di consentire questi URL tramite web.config

<system.web>
    <httpRuntime 
            requestPathInvalidCharacters="&lt;,&gt;,%,&amp;,:,\,?" />
</system.web>

Nota, ho appena rimosso l'asterisco (*), la stringa predefinita originale è:

<httpRuntime 
          requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?" />

Vedi questa domanda per maggiori dettagli.

Per me, sto lavorando su .net 4.5.2 con Web API 2.0, ho lo stesso errore, l'ho impostato semplicemente aggiungendo requestPathInvalidCharacters = "" in requestPathInvalidCharacters devi impostare caratteri non consentiti altrimenti devi rimuovere caratteri che causare questo problema.

<system.web>
     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
     <pages  >
      <namespaces>
     ....
 </namespaces>
    </pages> 
  </system.web>

** Si noti che non è una buona pratica, potrebbe essere un post con questo parametro poiché l'attributo di un oggetto è migliore o provare a codificare il carattere speciale. - Dopo aver cercato le migliori pratiche per la progettazione di API di riposo, ho scoperto che nella ricerca, nell'ordinamento e nella paginazione, dobbiamo gestire il parametro di query in questo modo

/companies?search=Digital%26Mckinsey

e questo risolve il problema quando lo codifichiamo e lo sostituiamo nell'URL di% 26 in ogni caso, sul server riceviamo il parametro corretto Digital & Mckinsey

questo link può essere d'aiuto nella migliore pratica di progettazione di api web di riposo https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

È necessario codificare il valore del percorso e quindi (se necessario) decodificare il valore prima di effettuare la ricerca.

Per me, durante la digitazione dell'URL, un utente ha utilizzato accidentalmente un / anziché un? per avviare i parametri della query

per esempio:

url.com/endpoint/parameter=SomeValue&otherparameter=Another+value

che avrebbe dovuto essere:

url.com/endpoint?parameter=SomeValue&otherparameter=Another+value

Questa eccezione si è verificata nella mia domanda ed era piuttosto fuorviante.

È stato generato quando stavo chiamando un metodo Web della pagina aspx utilizzando una chiamata al metodo ajax, passando un oggetto array JSON. La firma del metodo della pagina Web conteneva una matrice di un oggetto .NET fortemente tipizzato, OrderDetails. La proprietà Actual_Qty è stata definita come int e la proprietà Actual_Qty dell'oggetto JSON conteneva "4" (carattere spazio extra). Dopo aver rimosso lo spazio aggiuntivo, la conversione è stata resa possibile, il metodo Pagina Web è stato raggiunto correttamente dalla chiamata ajax.

Prova a impostare correttamente il server del progetto Web come IIS locale se è IIS Express. Assicurati che l'URL del progetto sia corretto e crea una directory viruale.

Nel trattare con Uniform Resource Locator (URL) ci sono alcuni standard di sintassi , in questa situazione particolare abbiamo a che fare con Personaggi riservati .

Fino a RFC 3986 , i caratteri riservati possono (o non possono) essere definiti come delimitatori dalla sintassi generica, da ciascuna sintassi specifica dello schema o dalla sintassi specifica dell'implementazione dell'algoritmo di dereferenziazione di un URI; E l'asterisco (*) è un carattere riservato.

La migliore pratica è usare Personaggi senza prenotazione negli URL oppure puoi provare a codificarli.

Continua a scavare :

• Riferimento alla codifica URL HTML (w3schools)
• Quando codificare o decodificare (RFC 3986)