710 messaggi dal 13 novembre 2008
Contributi
ciao, stavo provando una webapp core2 in locale con Kestrel, dopo i vostri ultimi articoli, e ho notato il problema della codifica dello slash del path:

link
http://aaa/build/25

la richiesta diventa
http://aaa/build%2F25

che nel mio caso viene indirizzata alla route errata....

cercando in rete il problema è noto
https://github.com/aspnet/Mvc/issues/6388

dato che è molto interessante la possibilità di usare Kestrel, è possibile ovviare a questo problema senza riscrivere tutte le route e/o path, ecc.?
cioè con un middlewear del tipo

public async Task Invoke(HttpContext context)
{

var requestPath = System.Net.WebUtility.UrlDecode(context.Request.Path);

context.Request.Path = requestPath;

await _next.Invoke(context);
}

sarebbe la soluzione ottimale?

grazie.
Modificato da teo prome il 30 gennaio 2018 12.37 -
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,
questa cosa non mi era mai capitato di vederla ma perché ha un effetto sulle tue route? Il middleware di routing non dovrebbe essere in grado di gestire la cosa?
Puoi fare un esempio di come sono configurate le tue route?


sarebbe la soluzione ottimale?

Penso di sì, del resto è la soluzione consigliata nella issue.

ciao,
Moreno

Enjoy learning and just keep making
710 messaggi dal 13 novembre 2008
Contributi
ciao,
anche io sono rimasto sorpreso e ho pensato la stessa cosa, in effetti per trovare l'arcano ci ho messo un po'.....
il route dei due constraint che vanno in conflitto, ma solo su Kestrel, è impostato così


                routes.MapRoute
      (
        name: "routeToBuild",
       template: "build/{pk}"
.... });

                routes.MapRoute
                (
                  name: "routeToStory",
                 template: "{story}"
... });



mandando
http://aaa/build/25

la richiesta diventa
http://aaa/build%2F25

che viene instradata sulla constraint 'routeToStory'

l'arcano, come riportato in github, sembra essere che il comportamento corretto, rispondente agli standard web, sia in realtà quello di Kestrel, IIS/Http.Sys aggiunge un decode per 'ragioni di sicurezza'.

Il senso di tutto questo secondo me, al di la della banalità o meno del problema specifico, non è affatto banale: se Kestrel (e tutto il resto) ha raggiunto la maturità (..si spera anche gli sviluppatori), abbiamo l'opportunità di abbracciare il cambiamento di rotta, d'altronde non è anche il senso di .Net Core?

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.