Request header field x-user-session is not allowed by Access-Control-Allow-Headers RRS feed

  • Question

  • I am trying to do a CORS call to a WCF service endpoint hosted on IIS7.5.

    I have configured custom headers in IIS. My configuration looks like below

                <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
                <add name="Access-Control-Allow-Headers" value="x-user-session,origin, content-type, accept" />
                <add name="Access-Control-Allow-Credentials" value="true" />

    When I do a POST request I get following error message "Request header field x-user-session is not allowed by Access-Control-Allow-Headers"

    If I remove my custom header from the call and run it, everything works fine.

    Also if I do a GET call with custom header then also API works correctly.

       success: function(d) { console.log(d) },
       timeout: 9000,
       url: "",
       data: JSON.stringify({"card_id":    1234,"expire_month":"11","expire_year":"2020","full_name":"Demo Account", "number":"4111111111111111","is_primary":true}),
       xhrFields: { withCredentials: true}, 
      headers: { x-user-session':  "B23680D0B8CB5AFED9F624271F1DFAE5052085755AEDDEFDA3834EF16115BCDDC6319BD79FDCCB1E199BB6CC4D0C6FBC9F30242A723BA9C0DFB8BCA3F31F4C7302B1A37EE0A20C42E8AFD45FAB85282FCB62C0B4EC62329BD8573FEBAEBC6E8269FFBF57C7D57E6EF880E396F266E7AD841797792619AD3F1C27A5AE" },
    crossDomain: true,
       contentType: 'application/json'

    Please help

    Friday, November 1, 2013 1:41 PM


  • Nice copy-paste job for the same question from StackOverflow :D -->
    Wednesday, November 6, 2013 8:38 AM

All replies

  • Most probably the issue is that the OPTIONS request is returning an error (404 or 405). This would explain why GET works properly (it doesn't always require preflight request) while POST don't (it always require preflight).

    Usually the easiest solution for WCF services hosted on IIS is to enable all methods through WebInvokeAttribute:



    Sometimes the IIS is blocking the OPTION request with its default OPTIONSVerbHandler. You can remove this handler through your web.config:


        <remove name="OPTIONSVerbHandler"/>


    In worst case scenario (when the OPTIONS is not blocked by IIS but can't be handled by WCF) you can set your own handler. In such scenario first you need to a simple class like the one below in an assembly:

    namespace CustomHandlers


        public class CORSOPTIONSVerbHandler : IHttpHandler


            public bool IsReusable


                get { return true; }


            public void ProcessRequest(HttpContext context)


                if (context.Response.HttpMethod == "OPTIONS")

                    context.Response.StatusCode = 200;


                    context.Response.StatusCode = 405;





    The new handler can be added in web.config like this:


        <remove name="OPTIONSVerbHandler"/>

        <add name="CORSOPTIONSVerbHandler" verb="OPTIONS" path="*" type="CustomHandlers.CORSOPTIONSVerbHandler, CustomHandlers"/>


    Of course you need to adjust the assembly, namespace and class name properly.

    • Proposed as answer by Mernández Tuesday, November 5, 2013 7:23 AM
    Tuesday, November 5, 2013 7:21 AM
  • Nice copy-paste job for the same question from StackOverflow :D -->
    Wednesday, November 6, 2013 8:38 AM
  • Hi tpeczek,

    Yes, it is copied from your excellent solution. And your excellent soluiton has solved @Saurabh's  the problem. So I will mark your solution as answer, then it will help the others who meet the same question as the @Saurabh.

    Best Regards,
    Amy Peng

    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.

    Friday, November 8, 2013 2:41 AM