1. #1
    Sencha User
    Join Date
    Nov 2011
    Location
    Munich, Germany
    Posts
    14
    Vote Rating
    0
    digitalwm is on a distinguished road

      0  

    Default Answered: REST Model Store Proxy calls with OPTIONS

    Answered: REST Model Store Proxy calls with OPTIONS


    Hi,

    I have the following situation:

    - Ext JS Models with Proxy that is using REST as service
    - The REST service is done in Node JS so it's now a usual HTTP server and it's binding on port 8080.

    The REST works perfect from a browser and from JQuery, BUT if I use it in the Ext JS model in functions like "load", "save" etc, the Ext JS Proxy calls the url with the method OPTIONS.

    Can anybody tell me how I can disable this? or how can I force the method? I want to mention that I used the config object where specifying the methods used for Create, Read, etc.

  2. When you say xHTML request, do you mean XMLHttpRequest?

    REST requests ultimately still use AJAX behind the scenes. An AJAX request cannot normally be sent to a server from a different origin.

    The easiest way to overcome same-origin issues is to proxy all requests through the same server. However this isn't always possible for load, performance, networking or security reasons.

    Traditionally the workaround for this is to use a JSON-P request. This takes advantage of the fact that SCRIPT tags can be injected into a page to point at any URL you like, thus sending a request. JSON-P is not as powerful as AJAX (for example, you don't get decent error handling and you can only use GET) but it is supported by all browsers. The server needs to support JSON-P for this to work. There is no such thing as JSON-P REST.

    XMLHttpRequest 2 introduced support for a feature known as CORS, cross-origin resource sharing. This provides a mechanism for making AJAX requests to a different origin. It isn't supported in older browsers (including IE 6 & 7) or Opera. Depending on your target browsers this may not be a problem.

    CORS works by sending the request to the server and then checking a response header to see whether the server allows cross-origin requests. Sometimes the request will just be sent as-is but only if it's a request that you could have made by other means (such as a form submit). For other requests they will be 'pre-flighted', where an OPTIONS request is sent first to check that the server is ok with the real request being sent. This is all done by the browser, it is totally transparent to the JavaScript code making the request.

    Only GET and POST requests can avoid pre-flighting, so if you're using REST you're stuck with it. By default ExtJS sets a request header on all AJAX requests and you'll need to disable that if you want to avoid pre-flighting with GET and POST. You'll also need to switch on the cors setting for IE support:

    Code:
    Ext.Ajax.useDefaultXhrHeader = false;
    
    // Can also be specified in the request options
    Ext.Ajax.cors = true;
    If you're interested in pursuing CORS I suggest the following as further reading:

    http://en.wikipedia.org/wiki/Cross-O...source_Sharing
    https://developer.mozilla.org/En/HTTP_access_control

    Just in case this wasn't clear, if you can do it with jQuery you can do it with ExtJS. These are browser restrictions, not library restrictions.

  3. #2
    Ext JS Premium Member tvanzoelen's Avatar
    Join Date
    Apr 2008
    Location
    Groningen - Netherlands
    Posts
    1,118
    Answers
    85
    Vote Rating
    30
    tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about

      0  

    Default


    Probably you do a crossdomain request. Proxy type jsonp can be used for crossdomain requests.

    Or in the api property you can try to add 8080 in the urls ... in the case your js files are served from that port.

  4. #3
    Sencha User
    Join Date
    Nov 2011
    Location
    Munich, Germany
    Posts
    14
    Vote Rating
    0
    digitalwm is on a distinguished road

      0  

    Default


    Ok, so if I got this right, I can make REST only from the same domain as the page itself? same as xHTML request? or can I make it to other domains?

    I thought that REST was non domain bounded. And if it is bounded that what's the purpose when you have xHTML requests. (joking)

    Thanks for your support.

  5. #4
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,604
    Answers
    543
    Vote Rating
    325
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    When you say xHTML request, do you mean XMLHttpRequest?

    REST requests ultimately still use AJAX behind the scenes. An AJAX request cannot normally be sent to a server from a different origin.

    The easiest way to overcome same-origin issues is to proxy all requests through the same server. However this isn't always possible for load, performance, networking or security reasons.

    Traditionally the workaround for this is to use a JSON-P request. This takes advantage of the fact that SCRIPT tags can be injected into a page to point at any URL you like, thus sending a request. JSON-P is not as powerful as AJAX (for example, you don't get decent error handling and you can only use GET) but it is supported by all browsers. The server needs to support JSON-P for this to work. There is no such thing as JSON-P REST.

    XMLHttpRequest 2 introduced support for a feature known as CORS, cross-origin resource sharing. This provides a mechanism for making AJAX requests to a different origin. It isn't supported in older browsers (including IE 6 & 7) or Opera. Depending on your target browsers this may not be a problem.

    CORS works by sending the request to the server and then checking a response header to see whether the server allows cross-origin requests. Sometimes the request will just be sent as-is but only if it's a request that you could have made by other means (such as a form submit). For other requests they will be 'pre-flighted', where an OPTIONS request is sent first to check that the server is ok with the real request being sent. This is all done by the browser, it is totally transparent to the JavaScript code making the request.

    Only GET and POST requests can avoid pre-flighting, so if you're using REST you're stuck with it. By default ExtJS sets a request header on all AJAX requests and you'll need to disable that if you want to avoid pre-flighting with GET and POST. You'll also need to switch on the cors setting for IE support:

    Code:
    Ext.Ajax.useDefaultXhrHeader = false;
    
    // Can also be specified in the request options
    Ext.Ajax.cors = true;
    If you're interested in pursuing CORS I suggest the following as further reading:

    http://en.wikipedia.org/wiki/Cross-O...source_Sharing
    https://developer.mozilla.org/En/HTTP_access_control

    Just in case this wasn't clear, if you can do it with jQuery you can do it with ExtJS. These are browser restrictions, not library restrictions.

  6. #5
    Sencha User
    Join Date
    Nov 2011
    Location
    Munich, Germany
    Posts
    14
    Vote Rating
    0
    digitalwm is on a distinguished road

      0  

    Default


    Thank you for the comprehensive explanation. I see now

  7. #6
    Ext JS Premium Member tvanzoelen's Avatar
    Join Date
    Apr 2008
    Location
    Groningen - Netherlands
    Posts
    1,118
    Answers
    85
    Vote Rating
    30
    tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about tvanzoelen has a spectacular aura about

      0  

    Default


    Thanks for the information. That Cross-Origin resource sharing is interesting.

    I think it is better to collect all the data from one single point, your own webserver (setup as proxy). Its possible to reach all sources from there.

    The big advantage is for example, if a foreign datasource is unreachable, you can handle your error/data handling yourself from a central point.

Thread Participants: 2

Tags for this Thread