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

  • This problem occurs when I try to query listdata.svc from JavaScript and Interface Language is set to Russian. Feb 7, 2013 at 13:17
  • I faced with the same problem with ru-RU locale :( How-to translate Field.Title to such escaped value? Maybe there is a solution for translation field names on client side using JS API? Apr 24, 2013 at 2:54

1 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:


But in ru-ru it becomes:


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


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:


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.

  • This is a known problem of the LINQ to SharePoint that is at the base of SharePoint REST. Another problem that stems from the same design decision to use Field.DisplayName for EDM (entity data model) property names leads to fragility in case of field or list renames. Oct 21, 2014 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.