Send data to the server

[KBazX 0]

The OverbyteIcsHttpPost1.pas file contains an example of how to use the SendStream property.
But, as I understand, this is not applicable to TSslHttpRest?
The RestRequest function contains the line of code:

FSendStream := Nil;

 

[Angus Robertson 647]

The old  OverbyteIcsHttpPost sample is for use with THttpCli.

 

If you are using TSslHttpRest, the OverbyteIcsHttpRestTst sample includes several ways of uploading data.   

 

POST is simply a command, servers accept uploads in many different ways, since they usually need to know the file name and other information.

 

Angus

 

[KBazX 0]

I need to send a json array like this as the request body:

[{"id": "0ab67665-49a7-4bd4-b111-8363b9ca07ba"},{"id": "3d9ebfd5-249f-468e-bcc5-6d5cb93f9ff6"},{"id": "a2b10f76-2218-41f2-b962-10f295c992d1"}]

I try this code:

HttpRest.RestParams.PContent := PContBodyJson;
HttpRest.RestParams.AddItem('id', '0ab67665-49a7-4bd4-b111-8363b9ca07ba', RPTypeStr);
HttpRest.RestParams.AddItem('id', '3d9ebfd5-249f-468e-bcc5-6d5cb93f9ff6', RPTypeStr);
HttpRest.RestParams.AddItem('id', 'a2b10f76-2218-41f2-b962-10f295c992d1', RPTypeStr);

The result is this request:

DELETE /api/items?{"id":"a2b10f76-2218-41f2-b962-10f295c992d1"} HTTP/1.0

That is, the array is not created due to the fact that in the TRestParams.AddItem function there is a call:

Index := IndexOf(aName);

It does not allow adding elements with the same name.

And the data itself is transmitted not in the request body, but in the url.

Please tell me how to do it correctly?
 

[Angus Robertson 647]

I'm not aware that the DELETE request is allowed to submit data as a body, this is not mentioned at:

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/DELETE

 

Which is why PContBodyJson is ignored.   If a body is allowed for DELETE, ICS will need to be updated

 

TRestParams does have an array method, RPTypeArray, used by AddItemAR(const aName: String; aValue: TStrings), but there is currently no way to create an array of objects in the manner you require, sorry I simply never anticipated it when designing the component, there are simply too many ways to build Json.  I'll put it on my list, but it may take a while. 

 

Meanwhile, you could build the Json with SuperObject or manually.

 

Angus

 

 

[omnibrain 18]

6 hours ago, Angus Robertson said:

I'm not aware that the DELETE request is allowed to submit data as a body

It's not: https://www.rfc-editor.org/rfc/rfc9110.html#name-delete

Neither is GET. I ran into some bug today (and occasionally before) when I accidentally send a body with GET something in the ICS-Server seems to break so the next request fails. But I had no time for further analysis yet.

[Angus Robertson 647]

Anything that crashes the ICS web server is something that should be fixed, if you are sure GET with body is fatal, I'll put it on my list to test and try and fix. 

 

I get thousands of hacking attempts on my public server daily, even have a dynamic blacklist to block repeats accesses, currently 4,600 IPs blocked for the last thee days.

 

Angus

 

 

[KBazX 0]

9 hours ago, Angus Robertson said:

Meanwhile, you could build the Json with SuperObject or manually.

Could you please tell me how to do it manually? Maybe there is some example?
The Send Stream property didn't work for me for the above reason.

[Kas Ob. 138]

13 hours ago, omnibrain said:

It's not: https://www.rfc-editor.org/rfc/rfc9110.html#name-delete

Neither is GET. I ran into some bug today (and occasionally before) when I accidentally send a body with GET something in the ICS-Server seems to break so the next request fails. But I had no time for further analysis yet.

DELETE can have content, also between all HTTP methods only GET and HEAD are not allowed to have content (but with a twist)

 

From the same section of the the RFC you referred to:

1) from https://www.rfc-editor.org/rfc/rfc9110.html#name-delete

Quote

• a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or

This imply, well it does not imply it does clearly say the error cause is no content.

 

2) from https://www.rfc-editor.org/rfc/rfc9110.html#name-get 

Quote

A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

So there is access where GET request is allowed to have content but only in special case with origin server is already on the same page with client, or lets say server and client has their own communication semantics, (their own API/SDK), in that case then such content is handled only by such server, other servers should drop it (drop the content) or refuse to serve with an error, the risk here is coming from request smuggling, this is interesting class of attacks against cache proxies and/or load balancers.

 

3) HEAD has the same paragraph as GET about request content.

 

4) Now back to (1) of DELETE, the same paragraph as GET and HEAD but we have specified error to return in case of absence of the content, in other words it is likely that there is generally defined semantics for DELETE (between client and server) hence the request content is needed.