ListData.svc mit komplexen Filtern, Internet Explorer, 400 Bad HTTP request,
-
10-12-2019 - |
Frage
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- Wenn ich zugreife
Lösung
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.