ListData.svc avec les filtres complexes, Internet Explorer, 400 Mauvais requête HTTP,

Question

J'ai un problème de compréhension de la façon dont ListData.svc peut être débogué avec IE8 et IE9.

J'ai une URL qui ressemble à ceci:hostname:8181/_vti_bin/listdata.svc/ImageBanners?$filter=endswith(Path,'TopLeft') et de Montrer eq vrai

Lorsque j'essaie d'accéder à l'aide d'IE8 de mon SharePoint serveur autonome je recevoir le message d'erreur 400.

Lorsque je demande la même URL à l'aide de Firefox, il fonctionne très bien.

En plus de cela hostname:8181/_vti_bin/listdata.svc/ImageBanners fonctionne comme il devrait l'être encore dans IE.Donc le problème semble être dans le $filter=endswith partie.

Cependant.Lorsque je demande la même URL, en utilisant IE8 ou adresse IP du serveur localhost je obtenir de bons résultats même avec des filtres complexes.

Quelqu'un peut-il, s'il vous plaît, jeter quelque lumière sur ce mystère?Pourquoi dois-je obtenir ce genre de comportement?

Infos supplémentaires:

• SharePoint est le russe et l'anglais de la version installée.
• Application SharePoint est à l'aide de l'authentification NTLM.
• L'Authentification anonyme dans IIS est désactivé.

• Fiddler montre que chaque ressource est demandée deux fois.La première fois que le serveur renvoie 401, puis 200 ou 400 selon le navigateur et l'URL (voir les détails ci-dessus).

  • Quand j'ai accès ListData.svc l'utilisation de Firefox correcte de la requête HTTP ressemble à ceci:

  Accepter:text/html, application/xhtml+xml, /
  Accept-Language:fr-fr
  User-Agent:Mozilla/5.0 (compatible;MSIE 9.0;Windows NT 6.1;WOW64;Trident/5.0)
  Accept-Encoding:gzip, deflate
  Connexion:Keep-Alive
  Cookie:WSS_KeepSessionAuthenticated={b3987daa-d463-415f-8fb3-d556c27e5bbf}
  Hôte:localhost:8181
  Autorisation:NTLM TlRMTVNTU...

  • Lors de l'utilisation de IE8 requête HTTP ressemble (avis lcid=1049.peut-être que pourrait être le problème?):

  Accepter:image/jpeg, image/gif, image/pjpeg, application/x-ms-application, de l'application/xaml+xml, application/x-ms-xbap, /
  Accept-Language:fr-fr
  User-Agent:Mozilla/4.0 (compatible;MSIE 7.0;Windows NT 6.1;WOW64;Trident/5.0;SLCC2;.NET CLR 2.0.50727;.NET4.0C;.NET4.0E;.NET CLR 3.5.30729;.NET CLR 3.0.30729;InfoPath.3)
  Accept-Encoding:gzip, deflate
  Connexion:Keep-Alive
  Cookie:lcid=1049;WSS_KeepSessionAuthenticated={b3987daa-d463-415f-8fb3-d556c27e5bbf}
  Autorisation:NTLM TlRMTVNTU...
  Hôte:nom d'hôte:8181

Answer 1

Je l'ai finalement épinglé. Il s'est avéré être la caractéristique du repos de SharePoint. Je devais prendre UI Langue en considération!

Par exemple, dans le cas de la locale EN-US, la requête de repos devrait ressembler à ceci:

? $ filtre= endswith ( chemin , 'foldername')

Mais en ru-ru, il devient:

? $ filter= endswith ( путь , 'foldername')

En outre, vous devez échapper aux lettres russes. Donc, finalement, il devrait ressembler à ceci:

? $ filtre= endswith (% d0% 9f% d1% 83% D1% 82% d1% 8c 8c "," foldername ")

Ce n'est pas le seul problème, cependant ... Le JSON que je reçois s'avère également être localisé. Par cela, je veux dire que les propriétés ont différents noms localisés . Par exemple, JSON retourné en FR-US:

{... "ModifiedByID": 1, "Copysource": NULL, "APPROBATIONSATUS": "0", "PATH": "/ Listes / ImageBanners / ButRight" ...}

en ru-ru:

{.... "кемизмененоid": 1, "источниккопии": null, "Состояниеутверждения": "0", "Путь": "/ listes / imagebanners / bowright" ...}

C'est un problème, car il est vraiment difficile de prédire les noms des propriétés pour différentes langues. J'espère que cette information sera utile Avertissement pour quelqu'un.