Les options du filtre OData échouent quand Uri a échappé à l'esperluette

Question

J'utilise actuellement OData v3, mais cela semble échouer (tout aussi différemment) dans OData v4.

Disons que je donne les résultats suivants Uri:
http://myurl.com/odata/SomeEndpoint filtre $ = 1 éq FieldID & top $ = 10

Parfait, tapez que dans Postman ou d'un navigateur, fonctionne très bien. Mais si je code l'Uri, il échoue.

HTML Encoding:
http://myurl.com/odata/SomeEndpoint filtre $ = FieldID éq 1 & amp; dessus $ = 10

Tout avant le caractère échappé va s'appliquer à la requête (donc $ filtre fonctionne toujours), mais tout ce qui suit le caractère échappé est ignoré ($ top n'est pas appliqué).

URI d'encodage (j'ai essayé les deux):?
http://myurl.com/odata/SomeEndpoint filtre $ = FieldID eq 1% 26 $ top = 10 http://myurl.com/odata/SomeEndpoint filtre $ = FieldID eq 1% 26% supérieur de $ = 10

Les deux causes OData pour lancer une exception lorsque vous essayez d'appliquer les options de requête avec l'erreur suivante (paraphrasé puisque c'est de la mémoire):

'&' is in invalid character in query string. 
$filter=FieldId eq 1&$top=10 

Comme vous pouvez le voir, cela est indésirable et un problème. Si mon client encodait son Uri avant d'envoyer une requête, cela ne fonctionnerait pas. En outre, les liens générés par OData dans le résultat sont codés, par exemple, le lien de la page suivante:

< lien rel = "next" href = "http://myurl.com/odata/SomeEndpoint?$filter= FieldID% 201% 20 éq & amp; $ sauter = 1"/>

OData ne semble pas à l'esprit les 20% (espace) qui fonctionne très bien, mais sauter $ est en fait ignoré à cause de l'esperluette échappé (& ampli ;) si vous venez de le changer pour une vraie esperluette (&) cela fonctionne très bien.

Y at-il un moyen de résoudre ce problème? Cela semble être un problème avec OData.

Pour référence est ici que je suis cartographie mes itinéraires:

#pragma warning disable CS0618 // OData v3 route mapping. 
config.Routes.MapODataRoute(
    routeName: "odata", 
    routePrefix: "odata", 
    model: model); 
#pragma warning restore CS0618 

Je ne fais quoi que ce soit personnalisé.

MISE À JOUR:
Quand je tournerai ma tête Accept à XML je reçois:
< link rel = "next" href = "http://myurl.com/odata/SomeEndpoint?$filter=FieldId% 201% 20 éq & amp; $ sauter = 1"/>

Quand je tournerai ma tête Accept I JSON obtenir:
odata.nextLink ":" http://webapi.mydlweb.com/api/test/odata/v3/Checks $ filter = StoreID%% 2040 20 éq & pagesize = 1? & $ skip = 1 "

Par le commentaire ci-dessous, le lien JSON est généré correctement. Je peux cliquer dessus et cela fonctionne parce que l'esperluette n'est pas encodée. Toutefois, le lien XML DOES coder l'esperluette et le fait donc ne pas fonctionner. Est-ce normal lors du codage XML?Comment alors le client sait-il quelles sont les esperluettes à "unencode" et lesquelles doivent être encodées? Par exemple, si vous utilisez une perluète à l'intérieur d'un filtre (pour ne pas séparer les chaînes de requête), il DOIT être encodé.

MISE À JOUR 2: Je suppose que c'est le codage XML, et c'est comme ça.

Answer 1

Vous ne pouvez pas échapper à l'esperluette dans un querystring et attendre de se comporter comme une esperluette dans une séquence d'échappement querystring. Cela n'a rien à voir avec odata, juste un comportement normal de la chaîne de requête. En l'échappant, l'analyseur ne l'interprétera pas comme un délimiteur de paires clé/valeur mais comme une esperluette littérale dans la valeur.

Exemple: Cette recherche google fonctionne:

https://www.google.com/search?safe=off&q=test 

Mais, celui-ci n'a pas:

https://www.google.com/search?safe=off%26q=test