Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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 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 "$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
share|improve this question
    
This problem occurs when I try to query listdata.svc from JavaScript and Interface Language is set to Russian. –  Denis Molodtsov Feb 7 '13 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? –  Yuiry.Vasilyev Apr 24 '13 at 2:54
add comment

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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