Gira: Can't send "&" sign in POST request

[caligula]

Hello,

I need to make an HTTP POST query from Gira HS and for some reason it seems that the HS always cut it short. I send it with the Ampersand:
Screenshot 2019-08-24 at 18.16.54.png


But then whatever is after the first & disappears:
Screenshot 2019-08-24 at 18.17.13.png
Any idea why?

It has to be a POST query with multiple parameters IN THE BODY.

Thanks for your insights!

[EugenDo]

I'm pretty sure it was sent.

As a test, put the „&“-sign in the front.

[caligula]

Thanks EugenDo, this was it, the debug output doesn't display the full thing and just happened to cut where the & sign was supposed to be in my case.

Now, I realize this is really how I treat the value back that's not working.

I've tried simple evaluations but it failed. So moving to regexp. If somebody can help me figure this out that would be great.

The result should be something like:

{gesamt: 0.706737, phase1: 0.380774, phase2: 0.224033, phase3: 0.10193}

(obviously, with all of the HTTP headers before that).

Thinking it had to be Python-specific Regexp, I used this format:

(gesamt\":)(\d?\.\d*)(,\"phase1\":)(\d?\.\d*)(,\"phase2\":)(\d?\.\d*)(,\"phase3\":)(\d?\.\d*)

which should give me the float I'm looking for in groups 2, 4, 6, 8. So to debug, I assigned group 1 to nothing and group 2 to a internal address

But evaluation doesn't seem to work fine:

[B](Recv: 282) 0x48 0x54 0x54 0x50 0x2f 0x31 0x2e 0x31 0x20 0x32 0x30 0x30 0x20 0x4f 0x4b 0xd 0xa 0x58 0x2d 0x50 0x6f 0x77 0x65 0x72 0x65 0x64 0x2d 0x42 0x79 0x3a 0x20 0x50 0x48 0x50 0x2f 0x35 0x2e 0x36 0x2e 0x31 0x30 0xd 0xa 0x56 0x61 0x72 0x79 0x3a 0x20 0x41 0x63 0x63 0x65 0x70 0x74 0x2d 0x45 0x6e 0x63 0x6f 0x64 0x69 0x6e 0x67 0xd 0xa 0x43 0x6f 0x6e 0x74 0x65 0x6e 0x74 0x2d 0x74 0x79 0x70 0x65 0x3a 0x20 0x74 0x65 0x78 0x74 0x2f 0x68 0x74 0x6d 0x6c 0x3b 0x20 0x63 0x68 0x61 0x72 0x73 0x65 0x74 0x3d 0x55 0x54 0x46 0x2d 0x38 0xd 0xa 0x54 0x72 0x61 0x6e 0x73 0x66 0x65 0x72 0x2d 0x45 0x6e 0x63 0x6f 0x64 0x69 0x6e 0x67 0x3a 0x20 0x63 0x68 0x75 0x6e 0x6b 0x65 0x64 0xd 0xa 0x44 0x61 0x74 0x65 0x3a 0x20 0x53 0x75 0x6e 0x2c 0x20 0x32 0x35 0x20 0x41 0x75 0x67 0x20 0x32 0x30 0x31 0x39 0x20 0x30 0x39 0x3a 0x33 0x33 0x3a 0x31 0x38 0x20 0x47 0x4d 0x54 0xd 0xa 0x53 0x65 0x72 0x76 0x65 0x72 0x3a 0x20 0x6c 0x69 0x67 0x68 0x74 0x74 0x70 0x64 0x2f 0x31 0x2e 0x34 0x2e 0x33 0x35 0xd 0xa 0xd 0xa 0x34 0x39[/B]
HTTP/1.1 200 OK
X-Powered-By: PHP/5.6.10
Vary: Accept-Encoding
Content-type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 25 Aug 2019 09:33:18 GMT
Server: lighttpd/1.4.35

49
[B](Gesamt: 2) (Work: 0) (Typ: RegExp) (OK: 0)[/B]

Any idea? Thanks!

[EugenDo]

Maybe this will help you....

This is my query, which works for me with HS:

RegEx.PNG

RegEx -- 2.PNG

Note the number of groups and variables.

The answer from your query doesn't fit to a JSON ... it starts with "49"?

[caligula]

Thanks, that worked. A few things to note:
- my JSON appeared as "49" or similar in the debug screen as you noted, and yet the actual JSON was correct, I think it is an issue/bug with the debug screen
- the reason I was hitting those issues is because there is a bug in the Expert 4.9 software (or my DB is somehow corrupted) but when you select a numeric type in the "Datablock" section, for assigning to an address, you pick a format, save, but then as you open again it is set to "default", even though there is actually another setting chosen behind it. This problem does NOT show up with the simple block, only with the complex ones. So I had the wrong setting set on some of the data items but it was all showing up as "default" so it took me time to find out it was not the case, only some of them actually had the right setting.