ListData.svc mit komplexen Filtern, Internet Explorer, 400 Bad HTTP request,

Question

Ich habe ein Problem damit, zu verstehen, wie ListData.svc kann mit IE8 und IE9 debuggt werden.

Ich habe eine URL, die so aussieht:hostname:8181/_vti_bin/listdata.svc/ImageBanners?$filter=endswith(Path,'TopLeft') und Show eq true

Wenn ich versuche, mit IE8 von meinem SharePoint-Standalone-Server darauf zuzugreifen, erhalte ich die Fehlermeldung 400.

Wenn ich dieselbe URL mit Firefox anfordere, funktioniert es einwandfrei.

Darüber hinaus hostname:8181/_vti_bin/listdata.svc/ImageBanners Funktioniert auch im IE wie es sein sollte.Das Problem scheint also in der zu liegen $filter=endswith Teil.

Jedoch.Wenn ich im IE8 dieselbe URL mithilfe der Server-IP-Adresse oder des lokalen Hosts anfordere, erhalte ich auch bei komplexen Filtern korrekte Ergebnisse.

Kann bitte jemand etwas Licht in dieses Rätsel bringen?Warum bekomme ich so ein Verhalten?

Zusätzliche Information:

• SharePoint hat eine russische und eine englische Version installiert.
• Die SharePoint-Anwendung verwendet die NTLM-Authentifizierung.
• Die anonyme Authentifizierung in IIS ist deaktiviert.

• Fiddler zeigt, dass jede Ressource zweimal angefordert wird.Beim ersten Mal gibt der Server 401 zurück und dann 200 oder 400, je nach Browser und URL (siehe Details oben).

  • Wenn ich zugreife ListData.svc Bei Verwendung von Firefox sieht die korrekte HTTP-Anfrage folgendermaßen aus:

  Akzeptieren:text/html, application/xhtml+xml, /
  Akzeptierte Sprache:en-US
  User-Agent:Mozilla/5.0 (kompatibel;MSIE 9.0;Windows NT 6.1;WOW64;Dreizack/5.0)
  Akzeptieren-Kodierung:gzip, entleeren
  Verbindung:Bleib am Leben
  Plätzchen:WSS_KeepSessionAuthenticated={b3987daa-d463-415f-8fb3-d556c27e5bbf}
  Gastgeber:localhost:8181
  Genehmigung:NTLM TlRMTVNTU...

  • Bei Verwendung von IE8 sieht die HTTP-Anfrage wie folgt aus (Hinweis lcid=1049.vielleicht könnte das das Problem sein?):

  Akzeptieren:image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, /
  Akzeptierte Sprache:en-US
  User-Agent:Mozilla/4.0 (kompatibel;MSIE 7.0;Windows NT 6.1;WOW64;Dreizack/5.0;SLCC2;.NET CLR 2.0.50727;.NET4.0C;.NET4.0E;.NET CLR 3.5.30729;.NET CLR 3.0.30729;InfoPath.3)
  Akzeptieren-Kodierung:gzip, entleeren
  Verbindung:Bleib am Leben
  Plätzchen:lcid=1049;WSS_KeepSessionAuthenticated={b3987daa-d463-415f-8fb3-d556c27e5bbf}
  Genehmigung:NTLM TlRMTVNTU...
  Gastgeber:Hostname:8181

Answer 1

Ich habe es endlich festgehalten.Es stellte sich heraus, dass es sich um die Funktion von SharePoint REST handelte.Ich musste es nehmen UI-Sprache in Betracht!

Im Falle des Gebietsschemas „en-us“ sollte die REST-Abfrage beispielsweise so aussehen:

?$filter=endswith(Weg,'Ordnernamen')

Aber in ru-ru wird es:

?$filter=endswith(Путь,'Ordnernamen')

Darüber hinaus müssen Sie russische Buchstaben entkommen.Im Endeffekt sollte es also so aussehen:

?$filter=endswith(%D0%9F%D1%83%D1%82%D1%8C",'Ordnernamen')

Das ist jedoch nicht das einzige Problem...Es stellt sich auch heraus, dass der JSON, den ich erhalte, lokalisiert ist.Damit meine ich, dass Eigenschaften haben verschiedene lokalisierte Namen.Beispielsweise wurde JSON in en-us zurückgegeben:

{..."ModifiedById":1,"CopySource":null,"ApprovalStatus": "0", "Path": "/Lists/ImageBanners/BottomRight"...}

in ru-ru:

{...."КемИзмененоId":1,"ИсточникКопии":null,"СостояниеУтверждения":"0","Путь":"/Lists/ImageBanners/BottomRight"...}

Das ist ein Problem, weil es wirklich schwierig ist, die Namen der Eigenschaften für verschiedene Sprachen vorherzusagen.Ich hoffe, diese Informationen sind eine nützliche Warnung für jemanden.