[jquery] POST wordt OPTION

[maxtz0r]

Wij zijn afgelopen week gigantisch veel tijd kwijt geraakt om het volgende:

Er is een WCF service die ik gebruik om een get en post te doen. Deze gets en posts gaan via jquery ajax. Met de gets hebben wij geen enkel probleem en dit gaat gewoon goed. Met de posts echter gebeurt er iets vreemds. In google chrome zie ik dat de Post door chrome wordt omgezet naar OPTION. Na wat googlen kwamen wij erachter dat Chrome een preflight doet en dat dit er dan voor zorgt dat het geen POST wordt maar een OPTION. Dit komt dan weer door CORS. Het zoeken naar CORS en bijbehorende fenomeen geeft ons ontzettend veel resultaat van soortgelijke problemen maar niks lijkt te helpen.

Onze web.config is aangepast zodat deze het volgende heeft:

XML:

            <customHeaders>
                <add name="Access-Control-Allow-Origin" value="*"/>
                <add name="Access-Control-Allow-Methods" value="*"/>
                <add name="Access-Control-Allow-Headers" value="Content-Type" />
            </customHeaders>

De ajax post die wij doen is:

JavaScript:

var plaap = '{"RegistrationDetails": ' + strFinalObj + '}';
        console.log(plaap); //json output
        jQuery.support.cors = true; //was een test
        $.ajax({
            type: "POST",
            url: APIregistration,
            data: plaap,
            contentType:"application/json",
            dataType: "json",
            success: function (msg) {
                console.log(msg);
            },
            error: function (xhr, ajaxOptions, thrownError) {
                console.log(xhr.status);
            }
            
        }).fail( function (msg) {
            console.log(msg);
        });

Wij hebben nu ondertussen heel veel geprobeerd maar niks werkt. Onder andere hebben wij een nieuwe webservice gemaakt die simpel 1 str accepteert en verder niets doet maar ook dit werkt niet. De ajax post hebben wij op verschillende plekken aangepast bijvoorbeeld de contenttype.
Het vreemde is dat wanneer ik de output van var plaap kopieer en gebruikt in google chromes extentie "advanced REST client" deze wel gewoon werkt. Google CHROME maakt er dan wel gewoon een POST van ipv OPTION. Ook wanneer ik mijn pagina in de zelfde webroot zet als de webservice dan doet deze het wel. Dit is echter geen optie gezien de webservice op een heel andere plek draait dan de website.

Het lijkt dus iets met CORS te maken te hebben maar ik kan niet ontdekken wat wij nog meer kunnen doen dan de web.config zo aanpassen dat deze alles accepteert(wat wij dus al hebben gedaan).

Iemand een idee?

[Verwijderd]

Ik heb hier een aantal maanden geleden ook problemen gehad. Ik weet niet precies meer wat de oplossing was, maar misschien heb je hier wat aan.

Probeer OPTIONS als laatst te zetten:

XML:

<add name="Access-Control-Allow-Methods" value="GET, PUT, POST, DELETE, OPTIONS" />

Verder heb ik:

JavaScript:

jQuery.support.cors = true;

En crossDomain:

JavaScript:

$.ajax({
   crossDomain: true,

[Janoz]

Het request wordt niet 'veranderd' in een OPTION. Het OPTION request wordt uitgevoerd om de headers op te vragen en vervoglens te controleren of het request daadwerkelijk uitgevoerd mag worden. Dit kan niet met een POST omdat je dan het request al gedaan hebt en pas daarna kunt controleren. Dat het op hetzelfde domein wel werkt is omdat dan de controle niet nodig is en er dus geen OPTION gedaan hoeft te worden.

Weet je zeker dat die headers ook meegegeven worden bij het OPTION request?

[maxtz0r]

Verwijderd schreef op maandag 07 juli 2014 @ 10:27:
Ik heb hier een aantal maanden geleden ook problemen gehad. Ik weet niet precies meer wat de oplossing was, maar misschien heb je hier wat aan.

Probeer OPTIONS als laatst te zetten:

XML:

<add name="Access-Control-Allow-Methods" value="GET, PUT, POST, DELETE, OPTIONS" />

Verder heb ik:

JavaScript:

jQuery.support.cors = true;

En crossDomain:

JavaScript:

$.ajax({
   crossDomain: true,

Voor de allow-methods gebruik ik een wildcard maar ook options op het laatst zetten werkt niet.
Overige oplossing had ik ook inderdaad geprobeerd maar nog geen succes.

Janoz schreef op maandag 07 juli 2014 @ 10:28:
Het request wordt niet 'veranderd' in een OPTION. Het OPTION request wordt uitgevoerd om de headers op te vragen en vervoglens te controleren of het request daadwerkelijk uitgevoerd mag worden. Dit kan niet met een POST omdat je dan het request al gedaan hebt en pas daarna kunt controleren. Dat het op hetzelfde domein wel werkt is omdat dan de controle niet nodig is en er dus geen OPTION gedaan hoeft te worden.

Weet je zeker dat die headers ook meegegeven worden bij het OPTION request?

Ik doe niet bewust wat met het setten van headers voor de OPTION request. Daarbij komt dat ik daar helaas niet zo in thuis ben. Onderstaand is de request header van de OPTION. Mis ik hier iets of staat hier iets verkeerds?

code:

Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:nl,en-US;q=0.8,en;q=0.6
Access-Control-Request-Headers:content-type
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive
Host:[b]url[/b]
Origin:null
Pragma:no-cache
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.103 Safari/537.36

[Janoz]

Het gaat voornamelijk om de response van het OPTION request. Staan daar de drie door jou toegevoegde headers in?

[maxtz0r]

De response is:

code:

Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods:*
Access-Control-Allow-Origin:*
Allow:POST
Cache-Control:private
Content-Length:1565
Content-Type:text/html; charset=UTF-8
Date:Mon, 07 Jul 2014 09:24:58 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET

[Janoz]

Geen idee of het uit maakt, maar die waarden komen niet overeen met hetgeen je in je startpost gezet hebt. Methods en Origin lijken me daarentegen gewoon goed.

Persoonlijk zou ik me niet teveel focussen op het option vs post verhaal. Daar zit je probleem niet. Het is normaal dat er eerst een option gedaan wordt. Blijkbaar beslist je browser op basis van het resultaat van de option dat het niet toegestaan is om een request naar een andere host te doen. Dat is het probleem dat je moet proberen op te lossen.

[maxtz0r]

Janoz schreef op maandag 07 juli 2014 @ 11:31:
Geen idee of het uit maakt, maar die waarden komen niet overeen met hetgeen je in je startpost gezet hebt. Methods en Origin lijken me daarentegen gewoon goed.

Persoonlijk zou ik me niet teveel focussen op het option vs post verhaal. Daar zit je probleem niet. Het is normaal dat er eerst een option gedaan wordt. Blijkbaar beslist je browser op basis van het resultaat van de option dat het niet toegestaan is om een request naar een andere host te doen. Dat is het probleem dat je moet proberen op te lossen.

Dat is dus het vreemde want ik kan de request wel doen vanuit mijn browser extensie en die zal ook localhost of iig een andere domain gebruiken.
Wat ik nu zie is dat zodra ik content-type 'application/json' meegeef aan de $.ajax call dan krijg ik een OPTIONS url '405 (Method Not Allowed) ' foutmelding.
Zodra ik 'text/plain' meegeef begint de server te zeuren want die verwacht json / xml en geeft een 500 internal server error.

De browser extensie geeft ook content-type application/json mee maar die mag kennelijk wel de methode uitvoeren want ik krijg netjes een 200 Ok met een response vanuit de webservice.
De header van de extensie ziet er als volgt uit:

POST /service.svc/name? HTTP/1.1
Host: url
Connection: keep-alive
Content-Length: 516
Cache-Control: no-cache
Pragma: no-cache
Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.103 Safari/537.36
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: nl,en-US;q=0.8,en;q=0.6

Wat mij opvalt bij deze header is dat de Host ook echt de url heeft van de webservice ipv localhost, is dit logisch?

[maxtz0r]

Het heeft mij weer een aantal uur gekost maar ik heb het nu wel werkend. bij deze mijn oplossing wellicht dat het ooit nog hulpvol is voor andere

Op 1 of andere manier werken de "Access-Control-Allow-*" settings in mijn web.config niet zoals ik verwacht. Op basis van deze post: http://praneeth4victory.w...9/405-method-not-allowed/ heb ik een global.asax toegevoegd en daarna werkte het wel.

Wat een drama

[Janoz]

maxtz0r schreef op maandag 07 juli 2014 @ 13:38:
Dat is dus het vreemde want ik kan de request wel doen vanuit mijn browser extensie en die zal ook localhost of iig een andere domain gebruiken.

Nee. De browser bepaalt uiteindelijk of iets wel of niet mag, niet de server. De extentie komt niet vanaf een domein. Het is een onderdeel dat je in je browser geïnstalleerd hebt. Tijdens de installatie van die extentie geef jijzelf goedkeuring dat hij dingen mag gaan doen.

Maar mooi dat het nu iig opgelost is.

[R4gnax]

maxtz0r schreef op maandag 07 juli 2014 @ 14:30:
Het heeft mij weer een aantal uur gekost maar ik heb het nu wel werkend. bij deze mijn oplossing wellicht dat het ooit nog hulpvol is voor andere

Op 1 of andere manier werken de "Access-Control-Allow-*" settings in mijn web.config niet zoals ik verwacht. Op basis van deze post: http://praneeth4victory.w...9/405-method-not-allowed/ heb ik een global.asax toegevoegd en daarna werkte het wel.

Wat een drama

En wat een non-oplossing.

De correcte oplossing voor oude WCF services is om een endpoint behavior te schrijven wat CORS support toevoegt. Niet om globaal aan de headers te gaan lopen frutten van alle mogelijke OPTION requests die nu en in de toekomst door je applicatie heen zullen gaan.

http://blogs.msdn.com/b/c...-cors-support-in-wcf.aspx

(Eigenlijk wil je updaten naar WebAPI, waar CORS support vziw tegenwoordig gewoon ingebakken zit.)

[ Voor 4% gewijzigd door R4gnax op 07-07-2014 21:18 ]

[Avalaxy]

Niet geheel correct, om CORS te gebruiken met Web API heb je Microsoft.AspNet.WebApi.Cors nodig. Inderdaad wel de moeite om te gebruiken, heeft ons een hoop problemen gescheeld. We probeerden het eerst zelf ook handmatig met headers op te lossen maar wat was slecht onderhoudbaar en werkte vaak niet.

[R4gnax]

Avalaxy schreef op maandag 07 juli 2014 @ 21:24:
Niet geheel correct, om CORS te gebruiken met Web API heb je Microsoft.AspNet.WebApi.Cors nodig. Inderdaad wel de moeite om te gebruiken, heeft ons een hoop problemen gescheeld. We probeerden het eerst zelf ook handmatig met headers op te lossen maar wat was slecht onderhoudbaar en werkte vaak niet.

Dus toch nog een optionele install in de Microsoft namespace? Jammer; maar goed, er is in elk geval een officiële MS versie. Da's al een flink eind in de richting sinds WebAPI 1.x.

[maxtz0r]

Avalaxy schreef op maandag 07 juli 2014 @ 21:24:
Niet geheel correct, om CORS te gebruiken met Web API heb je Microsoft.AspNet.WebApi.Cors nodig. Inderdaad wel de moeite om te gebruiken, heeft ons een hoop problemen gescheeld. We probeerden het eerst zelf ook handmatig met headers op te lossen maar wat was slecht onderhoudbaar en werkte vaak niet.

Dat is zeker de moeite waard om naar te kijken. Bedankt, staat gebookmarked en de volgende webservice zal zeker meer deze kant op gaan.