Custom http post request with headers

[Pierre Penninckx]

I tried to make a Http POST request using json as a payload but I can't make it work.

To do that, I need to add a "Content-Type: application/json" header. So I used Http.Request:

Http.request "POST" "http://localhost/jsonrpc" ( Json.toString " " json ) [("Content-Type", "application/json »)]

This does some weird stuff : it sends not a POST request anymore but an OPTIONS one.

What’s weirder is that if I use the exact same command without the headers (thus with an empty list), it sends a correct POST request.

I tried adding a ":" at the end of the header key but then I get :

"Failed to execute 'setRequestHeader' on 'XMLHttpRequest': 'Content-Type:' is not a valid HTTP header field name."

With curl I would do like this (in fact, I tested it and it works):

curl -X POST -d @request http://localhost/jsonrpc --header "Content-Type:application/json"

@request is a file containing the json object to send.

Does anybody have an idea what’s going on ?

For the record, I filed a github issue : https://github.com/evancz/Elm/issues/426

----

Pierre Penninckx   [ibiza...@gmail.com]

[Dobes Vandermeer]

Is it possible you're doing a cross-domain request?  That's one case where CORS support in the browser will send an OPTIONS to check for CORS support on the "server".

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

If you check the headers in the OPTIONS request to the server you might see an "Origin" header in there.

CORS only requires the OPTIONS request to be sent first if you add headers outside a particular set to the request, otherwise it just adds the "Origin" header to the request itself, thus the difference in behavior when you add the header.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pierre Penninckx]

Hi Dobes,

That is exactly it!

And of course the server I try to contact cannot send the Access-Control-Allow-Origin header…

A workaround would be to use a proxy to inject the missing header(s).

But I don’t think this is really portable since a proxy must be installed at browser level. And furthermore it’s cumbersome to make people install a proxy for that...

By the way, my situation is:

192.168.42.21:8000 sends a POST request to 192.168.42.21.8001 (explicitly, not to localhost:8001). Is it normal that it triggers a CORS?

----

Pierre Penninckx   [ibiza...@gmail.com]

[Dobes Vandermeer]

Hi Pierre,

Any change to the host, port, or scheme would be considered a cross-domain request.  So yes, since the port is different you can't do AJAX to the other host without using CORS or some other technique.

Googling for "cross domain AJAX" might turn up some relevant research material on the subject, including typical solutions like CORS, JSONP, Proxying, or using Flash.  All the solutions except for using a server-side proxy require cooperation from the target service, for security reasons.  Basically any service that uses Cookies or the Authentication header for authorization must not allow cross-domain requests, but if the API uses a query parameter, custom header, or field in the request body then it can allow cross-domain requests using JSONP or CORS since user agents won't automatically authorize the request in that case.  I think there is a flag in CORS that allows the server to specify that requests be allowed, but that Cookies should not be sent.

Cheers,

Dobes