I've spent too long trying to get an POST sent from code. It appears to be ending
up as an OPTIONS request instead.

My code: (myReq is a TServerRequest)

myReq.URL := m_szRESTURL + '/Answers';
myReq.Method := rmPost;
myReq.Params.Clear;
myReq.Params.Add('user=' + m_szRestMyID);
myReq.Params.Add('question=' + szQuestionID);
myReq.Params.Add('username=' + encodeURI(editEmail.Text));
myReq.Params.Add('password=' + encodeURI(editPassword.Text));
// myReq.RequestContent.Text := '<Value>' + szResponse + '</Value>';
// myReq.RequestHeaders.Values['Content-Length'] :=
IntToStr(Length(myReq.RequestContent.Text));

Report('Sending REST response to ' + myReq.URL);
Report('Params ' + myReq.Params.Text);
Report('Payload ' + myReq.RequestContent.Text);
Report('Headers ' + myReq.RequestHeaders.Text);
myReq.Execute;

This shows in Chrome's monitoring as the following:

Request
URL:http://myurl.cloudapp.net/Answers?user=13&question=3284779&username=nope&passwor
d=nope
## Request Headers
Access-Control-Request-Headersigin, content-type
Access-Control-Request-Method:POST
Origin:https://localhost
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/27.0.1453.94 Safari/537.36
## Query String Parameters
user:13
question:3284779
username:nope
password:nope


Compare with the monitoring of a RemObject's POST earlier in the session. The POST
is not even recognised in the EWB version, and it Chrome says it is doing an
OPTIONS call. My server doesn't do that, so it gets stuck, though EWB does handle
that okay.

Request URL:https://localhost/JSON?1370441661129
Request Method:POST
Status Code:200 OK
## Request Headers
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Content-Length:130
Content-type:application/x-www-form-urlencoded
Host:localhost
Origin:https://localhost
Referer:https://localhost/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/27.0.1453.94 Safari/537.36
## Query String Parameters
1370441661129:
## Form Data
{"blah":0}}:
## Response Headers
Accept-Encoding:gzip, identity
Access-Control-Allow-Origin:*
Connection:keep-alive
Content-Length:201
Content-Type:application/json; charset=ISO-8859-1
Server:RemObjects SDK


I also looked at the EWB framework source, and it had the 'Content-Length' code,
but when I do that I get an error from Chrome saying it isn't allowing a dangerous
header to be set (or some such).
Note also that the EWB version doesn't have any content, even though I added some.
In case it was relevant, I changed the "post" string to "POST" in the code as the
internet only uses uppercase, but that didn't seem to make any difference.

If anyone knows what I'm doing wrong, please say...

/Matthew Jones/

Matthew,

Your code looks ok.

I have some POST in my app and went and checked what it sends and it
works as expected (code looks similar to yours except i use
TServerRequestQueue - but that ends up just executing the TServerRequest
anyways).

My EWB app Chrome trace (start of it) shows:

Request
URL:http://192.168.0.225:8080/cws/wpage/d438792321?TEXT=Hello%20world
Request Method:POST
Status Code:200 OK

Request Headers
POST /cws/wpage/d438792321?TEXT=Hello%20world HTTP/1.1
Host: 192.168.0.225:8080
Connection: keep-alive
Content-Length: 0
Origin: http://192.168.0.225:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Content-Type: application/xml
Accept: */*
<snip>

I wonder if it's something to with cross origin - in my case app is
served from same web server that handles the post.

Raul


On 6/5/2013 11:47 AM, (Matthew Jones) wrote:
> I've spent too long trying to get an POST sent from code. It appears to be ending
> up as an OPTIONS request instead.
>
> My code: (myReq is a TServerRequest)
>
>   myReq.URL := m_szRESTURL + '/Answers';
>   myReq.Method := rmPost;
>   myReq.Params.Clear;
>   myReq.Params.Add('user=' + m_szRestMyID);
>   myReq.Params.Add('question=' + szQuestionID);
>   myReq.Params.Add('username=' + encodeURI(editEmail.Text));
>   myReq.Params.Add('password=' + encodeURI(editPassword.Text));
> // myReq.RequestContent.Text := '<Value>' + szResponse + '</Value>';
> // myReq.RequestHeaders.Values['Content-Length'] :=
> IntToStr(Length(myReq.RequestContent.Text));
>
>   Report('Sending REST response to ' + myReq.URL);
>   Report('Params ' + myReq.Params.Text);
>   Report('Payload ' + myReq.RequestContent.Text);
>   Report('Headers ' + myReq.RequestHeaders.Text);
>   myReq.Execute;
>
> This shows in Chrome's monitoring as the following:
>
> Request
> URL:http://myurl.cloudapp.net/Answers?user=13&question=3284779&username=nope&passwor
> d=nope
> ## Request Headers
> Access-Control-Request-Headersigin, content-type
> Access-Control-Request-Method:POST
> Origin:https://localhost
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/27.0.1453.94 Safari/537.36
> ## Query String Parameters
> user:13
> question:3284779
> username:nope
> password:nope
>
>
> Compare with the monitoring of a RemObject's POST earlier in the session. The POST
> is not even recognised in the EWB version, and it Chrome says it is doing an
> OPTIONS call. My server doesn't do that, so it gets stuck, though EWB does handle
> that okay.
>
> Request URL:https://localhost/JSON?1370441661129
> Request Method:POST
> Status Code:200 OK
> ## Request Headers
> Accept:*/*
> Accept-Encoding:gzip,deflate,sdch
> Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
> Connection:keep-alive
> Content-Length:130
> Content-type:application/x-www-form-urlencoded
> Host:localhost
> Origin:https://localhost
> Referer:https://localhost/
> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/27.0.1453.94 Safari/537.36
> ## Query String Parameters
> 1370441661129:
> ## Form Data
> {"blah":0}}:
> ## Response Headers
> Accept-Encoding:gzip, identity
> Access-Control-Allow-Origin:*
> Connection:keep-alive
> Content-Length:201
> Content-Type:application/json; charset=ISO-8859-1
> Server:RemObjects SDK
>
>
> I also looked at the EWB framework source, and it had the 'Content-Length' code,
> but when I do that I get an error from Chrome saying it isn't allowing a dangerous
> header to be set (or some such).
> Note also that the EWB version doesn't have any content, even though I added some.
> In case it was relevant, I changed the "post" string to "POST" in the code as the
> internet only uses uppercase, but that didn't seem to make any difference.
>
> If anyone knows what I'm doing wrong, please say...
>
> /Matthew Jones/
>

I should also add that I do 4 GET calls using a TServerRequest just before I do the
POST, and they all look good too. Therefore the POST is not working as expected,
but I cannot see why it is not right.

/Matthew Jones/

> I wonder if it's something to with cross origin - in my case app is
> served from same web server that handles the post.

Hmm, interesting. The CORS requirement did break it at first, but we allowed the
content to be used from anywhere. Plus the GET works okay.

I wonder therefore why my POST isn't shown the same. Hmm, why not hard code the URL
to the web server and see if it goes normal?
[clickety-tap]
Okay, yes, if I hard code the URL to the host server, it all looks proper in the
Chrome debug. The CORS thing must affect it somehow. Thank you for the suggestion -
I will go read the internet again.

/Matthew Jones/

Matthew,

<< This shows in Chrome's monitoring as the following: >>

Hmm, why is the Origin showing up as:

Origin:https://localhost

???

That's probably part of your problem.

<< I also looked at the EWB framework source, and it had the
'Content-Length' code, but when I do that I get an error from Chrome saying
it isn't allowing a dangerous header to be set (or some such). >>

The only place this should be set is in the LogOutput procedure, which is
used primarily within the IDE for debugging (and I've removed it, since it
isn't needed).

Tim Young
Elevate Software
www.elevatesoft.com

See My Post on Building Own HTTP Server - Mar 21, 2013

http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&msg=2470

2.  Chrome Browsers issue an HTTP OPTIONS request prior to the HTTP POST generated by a Database.Commit.  So your sever needs to respond to an OPTIONS request.

Walter

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:
> << This shows in Chrome's monitoring as the following: >>
>
> Hmm, why is the Origin showing up as:
>
> Origin:https://localhost
>
> ???

The app is designed to load from one site, but access REST services from
another. This works with GET, once the service was told to allow access
from other sites (CORS). It is POST that is not working, but as per the
other message, it seems to be CORS related. I will investigate that. The
long term aim is to have this phonegapped, so it will make more sense.

--
Matthew Jones

> 2.  Chrome Browsers issue an HTTP OPTIONS request prior to the HTTP
> POST generated by a Database.Commit.  So your sever needs to
> respond to an OPTIONS request.

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing says that the OPTIONS
request header is a mandated part of the spec, so thank you for that pointer. I am
learning so much about the browser environment, and it has mostly been flattened
before me.

We shall now have to work out how to get our server service on Azure to do the
necessary.

/Matthew Jones/

> We shall now have to work out how to get our server service on Azure to do the
> necessary.

And once enabled, not sure how, all is well. Thanks all.

--
Matthew Jones