501 not implemented, xml-atom

Aug 14, 2012 at 12:48 PM
Edited Aug 14, 2012 at 12:57 PM

Hi,


I currently use dataJS to read a flow xml-atom. When I use xhr object : no problem.But, if I use DataJS, I have a error "501 not implemented"  and the request method "GET" changes in "OPTION".

Code xhr : 

xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function () {
        if (xhr.readyState == 4 && (xhr.status == 200 || xhr.status == 0)) {
      
        }
    };

    xhr.open("GET", "fluxAtomAdress", true);
xhr.send(null);

 

 

Code datajs : 

OData.request(
       {
           requestUri: "fluxAtomAdress",
           headers: {
               "MaxDataServiceVersion": "2.0",
           }
       },
           function (data, request) {
               //code here
           },
           function (err, request) {
		//code here
           }
       );

 

 Request's headers : 

Xhr : 

GET /OData/OData.svc/Companies HTTP/1.1
Host: adresseFlux(An IP)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost:53018/
Origin: http://localhost:53018
Cache-Control: max-age=0

DataJs : 

OPTIONS /OData/OData.svc/Companies HTTP/1.1
Host: adressFlux(An Ip)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Origin: http://localhost:53018
Access-Control-Request-Method: GET
Access-Control-Request-Headers: maxdataserviceversion

request'response :

Xhr : 

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 35155
Content-Type: application/atom+xml;charset=utf-8
Server: Microsoft-IIS/7.0
DataServiceVersion: 2.0;
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type, Accept, MaxDataServiceVersion
Date: Tue, 14 Aug 2012 09:37:22 GMT


DataJS :

HTTP/1.1 501 Not Implemented
Content-Length: 217
Content-Type: application/xml
Server: Microsoft-IIS/7.0
DataServiceVersion: 1.0;
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type, Accept, MaxDataServiceVersion
Date: Tue, 14 Aug 2012 09:09:58 GMT

 

Servers(IIS 7) has property :

 

<add name="Access-Control-Allow-Headers" value="Content-Type, Accept, MaxDataServiceVersion" /> 
<add name="Access-Control-Allow-Origin" value="*" /> 

 

 

 If you could help me with my issues,

Thanks!

Marc Audefroy

Aug 20, 2012 at 11:10 AM

Hello All,

I still haven't solved my problem. Someone has an idea?

 Thanks!

Marc Audefroy

Aug 21, 2012 at 3:57 PM
Edited Aug 21, 2012 at 4:24 PM

I found new items in my problem. This is the header's property "MaxDataServiceVersion" that causes of the error. 

In the librairy on line 1064. If I write like this:

(the value of "MaxDataServiceVersion" is "2.0")

// Set the name/value pairs.
                if (request.headers) {
                    for (name in request.headers) {
                        if (name != "MaxDataServiceVersion")
                        xhr.setRequestHeader(name, request.headers[name]);
                    }
                }

 

It work...but not very good as solution...

After, a new problem appears :

If I use Google Chrome, it work, but if I use Mozilla. The request's response is empty. An idea? I feel that the callback is called too quickly.

Thanks,

 

Marc Audefroy

Aug 21, 2012 at 6:52 PM

Hi Marc,

   The reason for Mozilla behavior is that you are doing a cross domain request with custom headers set. Mozilla, since version 3.5 I believe, supports the CORS standard for cross domain requests. If the request has certain characteristicis (in the case of DataJS, adds custom headers to the request, like MaxDataServiceVersion) then Mozilla preflights it by first sending a request with the OPTIONS verb.  The endpoint doesn't support this http verb, so it responds with the HTTP 501 not implemented status.  If you try again the XHR code in your first example but setting a header of your own this time, you should get a 501 response as well.

   Blocking the addition of the MaxDataServiceVersion header is not a fix because it is required for proper communication with an OData endpoint (and you will hit the same problem with any other header you decide to add). I recommend strongly against such woraround. There are some ways of solving this, wich one you choose depends on your scenario.

1. If your only going to do GET requests from the endpoint you can use JSONP for the request.  This has the benefit of being comptible across browsers but your endpoint has to be capable of supporting JSON and the $format query option. Also keep in mind that you will always get JSON responses using this method.  JSONP is supported by DataJS but is disabled by default and you will have to enable it explicityly in your webapp. There are to ways to do it, globally by setting the flag odata.defaultHttpClient.enableJsonpCallback = true; or per request by setting the enableJsonpCallback property of the request object to true:

OData.read({ requestUri: "uri", enableJsonpCallback: true} , function (data) { 
    // success function
}, 
function (err) {
    // error function.
});

2. Seems that you own the endpoint and the server where it is hosted... since you added the access-control-* headers to the web server. If this is the case, then you can write som handler or interceptor that catches the OTPIONS request and replies with the appropriate headers. Keep in mind that CORS is still fairly new and starting to be adopted just recently and not all the browsers support it. For example, IE10 fully supports it, IE9 and 8 only support a subset of CORS via XDomainRequest object that is not useful for communicating with OData endpoints. Earlier versions don't support CORS at all. Please let me know if you own the endpoing and if it is WCF Data Services base so I can share with you an example of how you can handle this verb via a WCF Message Interceptor.

3. Have a service or controler in your web app that serves as a reverse proxy and relays the requests to other endpoints outside the web app domain. This is solution is compatible across all the browsers because for the browser would not be doing a cross domain request. Instead the request is made to the controler or the service in the same domain that served the web page.  The controler will then resend the request to its intended endpoint and rerout the response back to the web page.

Regards,

Alex Trigo

 

Aug 22, 2012 at 2:35 PM

Hi ATrigo,

Thanks for your response and explanations! :)

I used the first solution and it's worked =).

For the second solution, hum... I think this is not the best solution. It seems a little unwieldy. no?

I thought the same think for the third solution but I didn't want an intermediary between the javascript and Web Service.

Thank you again!

Regards,

Marc

Feb 18, 2013 at 8:54 PM
Hey Alex,

I'm running into the same problem with cross-browser compatibility as described by Marc. Unfortunatley option 1 won't work for me since I'm doing full CRUD via OData. You mention you have some code that implements option 2, I wonder if you could share it with me?
Apr 17, 2013 at 1:05 PM
Hi Alex,

I have also the same problem.

I'm using WCF Data Services. Can you please share your code snippet?

Thank you!
Nov 13, 2013 at 3:30 PM
I'm guessing there's little to no hope on a response to this - but I'm having the same issue - any progress/help available?
Dec 19, 2013 at 2:11 PM
Had the same problem.
Solution was to switch to jQuery.