There is an HTTP protocol error in the handling of parameters over TServerRequest.

If you specify a POST or PUT with rmPOST or rmPUT, the parameters over the network should not be passed on the URL like the are with the GET operation.  By default they should normally be passed as

  RequestContent.Add( optdata );
  RequestHeaders.Add('Content-Type:application/x-www-form-urlencoded');

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

erickengelke wrote:

> There is an HTTP protocol error in the handling of parameters over TServerRequest.
>
> If you specify a POST or PUT with rmPOST or rmPUT, the parameters over the network should not be passed on the URL like the are with the GET operation.  By default they should normally be passed as
>
>    RequestContent.Add( optdata );
>    RequestHeaders.Add('Content-Type:application/x-www-form-urlencoded');

Hmm, I've seen plenty where they are done both ways, and sometimes at the same time. I don't think you can safely say it should be one way or the other.

--

Matthew Jones

"Matthew Jones" wrote:

erickengelke wrote:

>> There is an HTTP protocol error in the handling of parameters over TServerRequest.
>>
>> If you specify a POST or PUT with rmPOST or rmPUT, the parameters over the network should not be passed on the URL like the are with the GET operation.  By default they should normally be passed as
>>
>>    RequestContent.Add( optdata );
>>    RequestHeaders.Add('Content-Type:application/x-www-form-urlencoded');

> Hmm, I've seen plenty where they are done both ways, and sometimes at the same time. I don't think you
> can safely say it should be one way or the other.

If you read through the RFCs, it is supposed to be passed with the simple x-www-form-urlencoded, or other formats like JSON.

Where this can run into problems is interoperability with other systems, where servers often require you to pass  userid/password as parameters with a POST for login.  While passing them on the URL technically passes, most web servers (NGINX, Apache) will log all parameters on the URL to a file, meaning you will have logs filled with userids and passwords of unsuspecting users.

Erick

--

Matthew Jones
EWB Programming Books and Component Library
http://www.erickengelke.com

I had a look at my code, and I have just been passing JSON in the RequestContent. I can see that it makes sense to have an option to ask that the Post should use the body for the parameters as you suggest, but it should be optional and if set then a RequestContent being there should cause an exception (you can't have both).


--

Matthew Jones

Erick,

<< There is an HTTP protocol error in the handling of parameters over TServerRequest. >>

Are you specifically talking about databases/datasets ?  Apart from that, the TServerRequest component makes no decisions for you in terms of how to handle parameter passing (URL vs. content).

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:


<< There is an HTTP protocol error in the handling of parameters over TServerRequest. >>

> Are you specifically talking about databases/datasets ?  Apart from that, the TServerRequest component makes no >decisions for you in terms of how to handle parameter passing (URL vs. content).

It's when you set Params.Values[xxx] on TServerRequests.

A person can override the default behaviour, but the default handling should not be on the Query part of the URL.

E
EWB Programming Books and Component Library
http://www.erickengelke.com

erickengelke wrote:

Tim Young [Elevate Software] wrote:


<< There is an HTTP protocol error in the handling of parameters over TServerRequest. >>

>> Are you specifically talking about databases/datasets ?  Apart from that, the TServerRequest component makes no >decisions for you in terms of how to handle parameter passing (URL vs. content).

>It's when you set Params.Values[xxx] on TServerRequests.

I found the error of my ways.  Instead of TServerRequest.Params.Values[] , one should set:

RequestContent.Params.Values[xxx] = 'blah';
RequestHeaders.Add('Content-Type:application/x-www-form-urlencoded');

It's slightly more manual, having to add the content type, but it has the desired effect, and nicely uses the Values feature of TStrings to manage the parameters.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

erickengelke wrote:

>  RequestHeaders.Add('Content-Type:application/x-www-form-urlencoded');

How about the ResponseContentType property instead?

--

Matthew Jones

"Matthew Jones" wrote:

erickengelke wrote:

>>  RequestHeaders.Add('Content-Type:application/x-www-form-urlencoded');

>How about the ResponseContentType property instead?

Yeah, that's better.  I also added the URLencode parameter magic to support passwords with exceptional characters.


E
EWB Programming Books and Component Library
http://www.erickengelke.com