stevarino

Still affects BDS 1.20.13.01.

Steps to Reproduce:
1. Run script-api command: `dimension.spawnParticle("minecraft:enchanting_table_particle", newLocation)` as documented in https://learn.microsoft.com/en-us/minecraft/creator/scriptapi/minecraft/server/dimension#spawnparticle

Observed Results:
Particle appears, but errors fill the content log, as described above.

Expected Results:
No errors.

Note: I was able to get rid of the `[Molang][error]-Error: accessing a variable that doesn't exist: variable.direction.x` by changing the above line the the folllowing:

molang.setSpeedAndDirection('variable.direction', 0.1, {
        x: newLocation.x - x, y: newLocation.y - y, z: newLocation.z - z});
      dimension.spawnParticle("minecraft:enchanting_table_particle", newLocation, molang);

But I can't seem to find a way to satisfy the error `[Molang][error]-Error: unhandled request for unknown variable `.x``

Updated title to reflect the more accurate case: this is only a difference on GET requests on Linux vs Windows. 

Test Code used:

import * as mc from "@minecraft/server";
import * as mcnet from "@minecraft/server-net";

async function timeout(ticks: number) {
  return await new Promise<void>(res => {
    mc.system.runTimeout(res, ticks);
  });
}

async function testMsg() {
  async function sendReq(method: mcnet.HttpRequestMethod) {
    const req = new mcnet.HttpRequest('http://httpbin.org/anything');
    req.setHeaders([new mcnet.HttpHeader('X-Custom', 'foo')]);
    req.setBody('Test test test.')
    req.setMethod(method)
    const res = await mcnet.http.request(req);
    console.log('Status:', res.status)
    console.log('Headers:', JSON.stringify(res.headers.map(h => [h.key, h.value])));
    console.log('Body:', res.body);
    console.log('.');
    console.log('.');
    console.log('.');
  }
  await sendReq(mcnet.HttpRequestMethod.Get);
  await timeout(60);
  await sendReq(mcnet.HttpRequestMethod.Post);
  await timeout(60);
  await sendReq(mcnet.HttpRequestMethod.Put);
  await timeout(60);
  await sendReq(mcnet.HttpRequestMethod.Delete);
}

testMsg();

Post, Delete, and Put all behaved identically.

Response (Windows) (note the data field with "Test test test"):

[2023-08-07 14:21:09:246 WARN] Web response body of unsupported content-type 'application/json' is being treated as 'text/plain'
[2023-08-07 14:21:09:280 INFO] [Scripting] Status: 200

[2023-08-07 14:21:09:282 INFO] [Scripting] Headers: [["access-control-allow-origin","*"],["access-control-allow-credentials","true"],["date","Mon, 07 Aug 2023 21:21:08 GMT"],["connection","keep-alive"],["content-type","application/json"],["content-length","398"],["server","gunicorn/19.9.0"]]

[2023-08-07 14:21:09:285 INFO] [Scripting] Body: {
  "args": {},
  "data": "Test test test.",
  "files": {},
  "form": {},
  "headers": {
    "Content-Length": "15",
    "Host": "httpbin.org",
    "User-Agent": "libhttpclient/1.0.0.0",
    "X-Amzn-Trace-Id": "Root=1-64d16044-1c5754f16c0b822c13e4e88c",
    "X-Custom": "foo"
  },
  "json": null,
  "method": "GET",
  "origin": "<REDACTED>",
  "url": "http://httpbin.org/anything"
}

Response Linux (note the empty data field):

[2023-08-07 21:40:31:341 WARN] Web response body of unsupported content-type 'application/json' is being treated as 'text/plain'
[2023-08-07 21:40:31:376 INFO] [Scripting] Status: 200

[2023-08-07 21:40:31:377 INFO] [Scripting] Headers: [["server","gunicorn/19.9.0"],["date","Mon, 07 Aug 2023 21:40:31 GMT"],["content-type","application/json"],["connection","keep-alive"],["content-length","378"],["access-control-allow-origin","*"],["access-control-allow-credentials","true"]]

[2023-08-07 21:40:31:377 INFO] [Scripting] Body: {
  "args": {},
  "data": "",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "libhttpclient/1.0.0.0",
    "X-Amzn-Trace-Id": "Root=1-64d164cf-488979347ad6527362eca3f5",
    "X-Custom": "foo"
  },
"json": null,
"method": "GET",
"origin": "<REDACTED>",
"url": "http://httpbin.org/anything"
}

Expected behavior here is that the two platforms should operate the same, either both allowing GET requests to have attached bodies, or for neither to allow bodies and to explicitly throw an exception when set.

Similar issue is MCPE-169433 but that appears unrelated.