ListData.svc with complex filters, Internet Explorer, 400 Bad HTTP request,

Question

I have a problem understanding how ListData.svc can be debugged using IE8 and IE9.

I have a URL that looks like this: hostname:8181/_vti_bin/listdata.svc/ImageBanners?$filter=endswith(Path,'TopLeft') and Show eq true

When I try to access it using IE8 from my SharePoint standalone server I receive error 400.

When I request the same URL using Firefox it works just fine.

On top of that hostname:8181/_vti_bin/listdata.svc/ImageBanners works as it should be even in IE. So the problem seems to be in the $filter=endswith part.

However. When I request the same URL in IE8 using server IP address or localhost I get correct results even with complex filters.

Can anyone, please, shed some light on this mystery? Why do I get this kind of behavior?

Additional info:

• SharePoint has Russian and English version installed.
• SharePoint Application is using NTLM authentication.
• Anonymous Authentication in IIS is disabled.

• Fiddler shows that every resource is requested twice. The first time the server returns 401, and then 200 or 400 depending on browser and URL (see details above).

  • When I access ListData.svc using Firefox correct HTTP request looks like this:

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

  • When using IE8 HTTP request looks like (notice lcid=1049. maybe that could be the problem?):

  Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, /
  Accept-Language: en-US
  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
  Connection: Keep-Alive
  Cookie: lcid=1049; WSS_KeepSessionAuthenticated={b3987daa-d463-415f-8fb3-d556c27e5bbf}
  Authorization: NTLM TlRMTVNTU...
  Host: hostname:8181

Answer 1

I have finally pinned it down. It turned out to be the feature of SharePoint's REST. I needed to take UI language into consideration!

For instance, in case of en-us locale the REST query should look like this:

?$filter=endswith(Path,'FolderName')

But in ru-ru it becomes:

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

Moreover, you need to escape Russian letters. So, finally it should look like this:

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

This is not the only problem, however... The JSON I receive also turns out to be localized. By this I mean that properties have different localized names. For example, returned JSON in en-us:

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

in ru-ru:

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

It's a problem, because it's really hard to predict the names of the properties for different languages. I hope this info will be useful warning for someone.