none
Why the preflight call is always trigger for AJAX calls RRS feed

  • Question

  • My Office App runs HTML/JS on the local machine and it calls some REST services on a server. The REST services have CORS support enabled but they don't handle the preflight call scenario (OPTIONS method call). By reading the CORS W3 standard, our calls should be simple method call and the preflight shouldn't be triggered. I guess we can always add the preflight call handling on the services on the server but would be nice if we don't have to add it.

    Any suggestions?

    Friday, January 10, 2014 5:00 PM

Answers

  • Hi,

    What's the Ajax Protocol, http or https?

    If it is https, Apps for Office will use "CONNECT" to create a tunnel.

    According to the link below:

    https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Preflighted_requests

    It uses methods other than GET, HEAD or POST.  Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted.

    So I suspect that Ajax calling in Apps for Office via https protocol may cause preflight being triggered. And I'm afraid there are no workaround.

    If this issue is caused by other reasons, I suggest you to repost your question to IE forum rather than Apps for Office Forum.

    Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by Marvin_Guo Friday, January 24, 2014 2:21 AM
    Tuesday, January 21, 2014 5:44 AM

All replies

  • Hi,

    Rather, the preflight mechanism benefits servers that were developed without an awareness of CORS, and it functions as a sanity check between the client and the server that they are both CORS-aware. The developers of CORS felt that there were enough servers out there that were relying on the assumption that they would never receive, e.g. a cross-domain DELETE request that they invented the preflight mechanism to allow both sides to opt-in. They felt that the alternative, which would have been to simply enable the cross-domain calls, would have broken too many existing applications.

    There are three scenarios here:

    1. Old servers, no longer under development, and developed before CORS. These servers may make assumptions that they'll never receive e.g. a cross-domain DELETE request. This scenario is the primary beneficiary of the preflight mechanism. Yes these services could already be abused by a malicious or non-conforming user agent (and CORS does nothing to change this), but in a world with CORS the preflight mechanism provides an extra 'sanity check' so that clients and servers don't break because the underlying rules of the web have changed.

    2. Servers that are still under development, but which contain a lot of old code and for which it's not feasible/desirable to audit all the old code to make sure it works properly in a cross-domain world. This scenario allows servers to progressively opt-in to CORS, e.g. by saying "Now I'll allow this particular header", "Now I'll allow this particular HTTP verb", "Now I'll allow cookies/auth information to be sent", etc. This scenario benefits from the preflight mechanism.

    3. New servers that are written with an awareness of CORS. According to standard security practices, the server has to protect its resources in the face of any incoming request -- servers can't trust clients to not do malicious things. This scenario doesn't benefit from the preflight mechanism: the preflight mechanism brings no additional security to a server that has properly protected its resources.

    Regards,

    Monday, January 13, 2014 12:13 PM
  • Hi Mercop002, thanks for your reply.

    Ours is your scenario 3. Moreover, my original question is that the CORS standards say the preflight call should not be triggered if it is a simple method call. Why IE browser triggers the preflight call for my simple method call? Is there a way to disable the preflight call since it is not needed for our case?

    Friday, January 17, 2014 7:21 PM
  • Hi,

    What's the Ajax Protocol, http or https?

    If it is https, Apps for Office will use "CONNECT" to create a tunnel.

    According to the link below:

    https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Preflighted_requests

    It uses methods other than GET, HEAD or POST.  Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted.

    So I suspect that Ajax calling in Apps for Office via https protocol may cause preflight being triggered. And I'm afraid there are no workaround.

    If this issue is caused by other reasons, I suggest you to repost your question to IE forum rather than Apps for Office Forum.

    Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    • Marked as answer by Marvin_Guo Friday, January 24, 2014 2:21 AM
    Tuesday, January 21, 2014 5:44 AM
  • Hi Marvin,

    What I am currently using is an HTTPS call. It does issue a CONNECT call to create SSL tunnel. However, the odd thing is that the same code doesn't trigger the preflight call if it runs in a standalone IE browser.

    Is this because the Office App runtime environment imposes more security restrictions?


    • Edited by Seangle Friday, January 24, 2014 6:55 PM
    Friday, January 24, 2014 4:45 PM
  • Sorry Marvin, I need to make a correction. My standalone IE case is not an apple to apple comparison because I open the HTML file from file system which is not HTTP. If I open the HTML file hosted on an HTTP server at localhost, the preflight call is triggered as well.

    Moreover, my GET call has an HTTP header "authorization" which triggers the preflight call. I think this is an expected behavior as the authorization header is not a simple header according to CORS.

    Sunday, January 26, 2014 3:56 PM