HTTP in from external failing if there is anything in the request body on RC servers
complete
Sasun Steinbeck
on the 5th I started seeing failures with external HTTP in requests to inworld objects... Failing with a 502 Proxy error. After some experimenting, it only happens on RC BlueSteel, RC LeTigre, and RC Magnum servers that I've tested on, AND the POST body must be non-empty. If I do a post with no body (from external, i.e. my web server) with an empty body, it works everywhere. With ANYTHING in the body, it fails on RC servers.
non-RC release regions do not fail! Everything works fine. GET requests all work fine everywhere, too. It's only POST, with body, to objects in RC regions from outside SL.
I've been making many HTTP-in POST requests from my web server daily to objects all over the grid for a very long time now. I haven't changed a thing and this new behavior just started showing up a few days ago out of the blue. It's causing some of my scripted products to completely fail to function, it's a really big problem for customers. This affects RFL inworld fundraiser kiosk servers so this could cause a big disruption to their fundraiser. However they may be able to temporarily mitigate by moving all their inworld servers to a non-RC region.
This is a really big problem for me since I have no access to a non-RC region. All my land is apparently RC.
Log In
This post was marked as
complete
Monty Brandenberg
While I'm somewhat happy asp.net did this and gave us a test case to find a problem, I do have a comment on the 'Expect:' header. This was a clumsy and poorly-thought-out addition to HTTP to design a special-purpose pre-flight mechanism into the protocol. It's effect is to turn every POST and PUT into a two-request action: a small pre-flight up front followed by a payload delivery operation (after a possible pointless waiting period). This increases latency on
every
request and is only ever a benefit on heavy-weight requests that are often failed early. (And makes me wonder why asp.net made it the default.) Disabling or sending an empty 'Expect:' header should result in overall better latency if you care about that.Maestro Linden
Sasun Steinbeck LiamHoffen Resident Hi guys, we have a fix for this issue up on aditi, on version Spring Break 2024-06-11.9458617693. If you have a moment, could you give that a try with your applications?
Update: the build with the fix also went out to all the Agni RC channels yesterday, so this issue should be fixed grid-wide on Agni
My own test script is behaving properly in this version when I include the "Expect: 100-continue" header, including cases in which the POST data approaches or exceeds the 2048 byte limit.
secondlife://Aditi/secondlife/Cloud%20Sandbox%204/128/128/27 is one script-friendly location on that version
Maestro Linden
Merged in a post:
HTTP In - RC Region fails receiving messages with more than 1024 characters.
LiamHoffen Resident
On Second Life Server regions, I'm able to post data of approximately 1500 bytes to my in-world objects. When I take the same object to an RC region (Taejin, Second Life RC Magnum 2024-06-03.9357471418), the event is not triggered at all if the data is over 1024 bytes in length.
Manually testing incoming messages on the RC region, just sending garbage data, I can get all up to a length that doesn't exceed 1024 bytes. Once the data is over that length, nothing arrives to the http_request hander.
Its important to note, the incoming data isn't truncated. No event is triggered at all.
Data sent is utf-8, although it almost seems as if the server is assuming its multibyte data, and then limiting per the 2048 byte limit in the http_request wiki sheet.
This seems to have begun a while back, but I can't identify an actual date the failure was first noticed.
LiamHoffen Resident
The data being sent is arriving from outside SL. To simulate that, I used the following PHP code. Simply replace the $host url with that gotten by your http receiver. Modify the $lenToSend variable to see success/failure on RC regions.
<?php
/*
replace $host with the value you got for your listening URL
modify lenToSend to 1024 or less for success on an RC region
when lenToSend is over 1024 on an RC region, we don't get anything at the receiver
*/
$host = "http://simhost-01852fa067936bae0.agni.secondlife.io:12046/cap/17d5d0e3-65d9-4d14-0093-f5d0ce323d3a";
$lenToSend = 1025;
$data = "THIS MIGHT HURT (triggered by web page)";
function http_request($Host, $PostData = "")
{
$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $Host);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, $PostData);
curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 5);
curl_setopt($curl, CURLOPT_TIMEOUT, 5);
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);
$response = curl_exec ($curl);
if ($response != "OK")
{
$httpcode = curl_getinfo($curl, CURLINFO_HTTP_CODE);
echo "Failed sending message with length of " . strlen($PostData) . " to {$Host}<br>";
$errorNo = curl_errno($curl);
$errorText = curl_error($curl);
echo "Error: {$errorNo} - {$errorText}<br>";
}
curl_close ($curl);
return $response;
}
while (strlen($data) < $lenToSend)
$data .= "x";
$response = http_request($host, $data);
echo "We sent [{$data}] to {$host}<br>We got back [{$response}]<br>";
?>
Maestro Linden
LiamHoffen Resident: It looks like your script is sending 1025 'x' characters, so I attempted to replicate the request with curl. However, it's still working for me:
# Generate a 1025-character string of "x"
% head -c 1025 < /dev/zero | tr '\0' x > x.txt
% wc -c x.txt
1025 x.txt
# POST the 1025 'x' to a script:
% curl -v --data @x.txt http://simhost-01d3500f306966b31.agni.secondlife.io:12046/cap/93e53279-d7d2-4c8c-60bc-dd3f4226a7f9
* Host simhost-01d3500f306966b31.agni.secondlife.io:12046 was resolved.
* IPv6: (none)
* IPv4: 54.184.248.43
* Trying 54.184.248.43:12046...
* Connected to simhost-01d3500f306966b31.agni.secondlife.io (54.184.248.43) port 12046
> POST /cap/93e53279-d7d2-4c8c-60bc-dd3f4226a7f9 HTTP/1.1
> Host: simhost-01d3500f306966b31.agni.secondlife.io:12046
> User-Agent: curl/8.6.0
> Accept: */*
> Content-Length: 1025
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200
< Date: Mon, 10 Jun 2024 22:12:23 GMT
< Server: Second Life LSL/Second Life Preflight 2024-06-03.9357471418 (http://secondlife.com)
< X-LL-Request-Id: Zmd6R88jdeNjk6JESdjNeQAAAJ4
< Content-Length: 17
< Cache-Control: no-cache, max-age=0
< Content-Type: text/plain; charset=utf-8
< Pragma: no-cache
< X-SecondLife-Local-Position: (234.737137, 118.845184, 20.893150)
< X-SecondLife-Local-Rotation: (0.000000, 0.000000, 0.000000, 1.000000)
< X-SecondLife-Local-Velocity: (0.000000, 0.000000, 0.000000)
< X-SecondLife-Object-Key: 0f97206a-64e7-4b91-6913-1e03d288dc61
< X-SecondLife-Object-Name: Basic HTTP-in test
< X-SecondLife-Owner-Key: e1a51880-d7b5-4c00-800d-91664f5b84c0
< X-SecondLife-Owner-Name: Maestro Linden
< X-SecondLife-Region: By Design (261376, 246784)
< X-SecondLife-Shard: Production
< Connection: close
<
* Closing connection
POST acknowledged%
in-world view:
```
[15:12] Basic HTTP-in test: Requesting HTTP-in URL in Second Life Preflight 2024-06-03.9357471418
[15:12] Basic HTTP-in test: Got URL_REQUEST_GRANTED. Send your requests to http://simhost-01d3500f306966b31.agni.secondlife.io:12046/cap/93e53279-d7d2-4c8c-60bc-dd3f4226a7f9
[15:12] Basic HTTP-in test: 2024-06-10T22:12:23.700898Z Got a POST request from user-agent: 'curl/8.6.0' with body length 1025. Last characters in the body are 'xxxxxxxxxxxxxxxxxxxx'
Is there any way to see what headers your script is sending in the request? The server might be sending some extra headers that trigger a problem, such as what ASP.net apps send, as described in https://secondlife.canny.io/server-bugs/p/http-in-from-external-failing-if-there-is-anything-in-the-request-body-on-rc-ser
LiamHoffen Resident
Maestro Linden:
I enabled the following in my curl request:
curl_setopt($curl, CURLINFO_HEADER_OUT, true);
curl_setopt($curl, CURLOPT_VERBOSE, true);
After calling the url on an RC region and on a region with Second Life Server, I get the following response:
$res2 = curl_getinfo($curl, CURLINFO_HEADER_OUT);
produces:
POST /cap/f8a23236-4294-375f-3577-ee23ca824eef HTTP/1.1
Accept:
/
Content-Length: 1025
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
Please let me know if anything else is needed.
Regards,
Liam
Maestro Linden
LiamHoffen Resident: Thanks for the info! I think the
Expect: 100-continue
header is triggering the bug, independent of POST content-length. At least that's how the failure in this issue (also reported against the RCs over the weekend) is triggered: https://secondlife.canny.io/server-bugs/p/http-in-from-external-failing-if-there-is-anything-in-the-request-body-on-rc-serLiamHoffen Resident
Maestro Linden:
After reading the linked topic, I removed the 100-continue header entry. With that, I can get messages set for 2000 bytes in length.
Thank you for pointing me back to that post. I read it earlier, but since that indicated no data came at all, I believed it didn't apply to my case. My was certainly message length that was causing the failure.
But, having that identified, I think this topic can either be closed or linked somehow back to the first. I do believe the data length is the trigger for the failure, so it may be helpful finding why Second Life Servers work differently than RC servers.
I appreciate your time you put to this case. Thank you.
Liam Hoffen
Maestro Linden
Hi LiamHoffen Resident can you please attach the test data that you're using in the request body?
I tried using the script below, containing text from the http_request wiki page (also included below). When I POST the data with curl on either Second Life Server 2024-04-13.8669470296 or Second Life RC BlueSteel 2024-06-03.9357471418, the script gets 1983 bytes of data, including the very end of the post data - as expected.
% curl --data @testdata.txt http://simhost-039d5e91e93cab1cd.agni.secondlife.io:12046/cap/6d266843-9a1c-00b0-0ecc-5b379a32da18
POST acknowledged%
[11:41] Basic HTTP-in test: Requesting HTTP-in URL in Second Life RC BlueSteel 2024-06-03.9357471418
[11:41] Basic HTTP-in test: Got URL_REQUEST_GRANTED. Send your requests to http://simhost-039d5e91e93cab1cd.agni.secondlife.io:12046/cap/481013ba-8120-747b-a46a-1438d2d6914e
[11:41] Basic HTTP-in test: 2024-06-10T18:41:47.402030Z Got a POST request from user-agent: 'curl/8.6.0' with body length 1983. Last characters in the body are '/or estate managers.'
default
{
on_rez(integer change)
{
llResetScript();
}
state_entry()
{
llOwnerSay("Requesting HTTP-in URL in " + llGetEnv("sim_channel")
+ " " + llGetEnv("sim_version"));
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_DENIED)
{
llOwnerSay("Got URL_REQUEST_DENIED - No free URLs!");
}
else if (method == URL_REQUEST_GRANTED)
{
llOwnerSay("Got URL_REQUEST_GRANTED. Send your requests to " + body);
}
else if (method == "GET")
{
llOwnerSay(llGetTimestamp() + " Got a GET request from user-agent: '"
+ llGetHTTPHeader(id, "user-agent") + "'");
llHTTPResponse(id, 200, "Hello there!");
}
else if (method == "POST")
{
llOwnerSay(llGetTimestamp() + " Got a POST request from user-agent: '"
+ llGetHTTPHeader(id, "user-agent") + "' with body length "
+ (string)llStringLength(body) + ". Last characters in the body are '"
+ llGetSubString(body, -20, -1) + "'");
llHTTPResponse(id, 200, "POST acknowledged");
}
else
{
llOwnerSay(llGetTimestamp() + " Got an unsupported " + method + " request from user-agent: '"
+ llGetHTTPHeader(id, "user-agent") + "' with body '" + body + "'");
llHTTPResponse(id, 405, "Unsupported Method");
}
}
}
Test data:
body is limited to 2048 bytes; anything longer will be truncated to 2048 bytes.
As per the above, this function is unaffected by any values passed to llHTTPRequest via HTTP_BODY_MAXLENGTH, as they reside on the Outgoing pipeline, and this function is on the Incoming pipeline.
headers (accessed with llGetHTTPHeader) are limited to 255 bytes.
There is a limit of 64 pending http_request
body is not sent with the request unless the method is set to "POST", "PUT", or URL_REQUEST_GRANTED.
Requests may fail with a 503 status code for at least two possible reasons:
if the returned body is ERROR: The requested URL could not be retrieved, and (111) Connection refused, the problem will normally last only a few minutes - this is th nightly maint & log rotation. It does reliably impact object to object HTTP at that time, and quite probably may impact object to/from web around the same time. The interruption in service is fairly brief, and the precise timing may vary as LL adjust their nightly maint processes, or due to server load.
this response can also happen if too many requests are received by scripts in the region owned by the same owner. In this case, a Retry-After header is returned with a number of seconds to wait before retrying. Note that if you have many requestors, some of them may have to wait longer. A good general strategy is to wait the suggested number of seconds (possibly with a little randomness added in) before retrying, and if that fails increase how long you wait by multiplying by a small number before retrying again. If all your requestors follow some method like this, eventually they'll get through.
All Issues ~ Search JIRA for related Bugs
Examples
See LSL_http_server/examples for some examples from the feature design phase.
KBcaution.png Important: Never ever forget to release a URL again which you have requested! URLs are region resources just like prims. If you take them all you can get into big trouble with the sim owner and/or estate managers.
Maestro Linden
tracked
Maestro Linden
Nice digging. I can reproduce the timeout error on Second Life RC BlueSteel 2024-06-03.9357471418 when sending the "Expect: 100-continue" header in my request; a proxy error is returned after 30 seconds:
% time curl -v --data "No patience" http://simhost-023b821757dd43606.agni.secondlife.io:12046/cap/fa8ab3a2-d471-7390-03db-e25d497a99ed -H "Expect: 100-continue"
* Host simhost-023b821757dd43606.agni.secondlife.io:12046 was resolved.
* IPv6: (none)
* IPv4: 35.90.97.27
* Trying 35.90.97.27:12046...
* Connected to simhost-023b821757dd43606.agni.secondlife.io (35.90.97.27) port 12046
> POST /cap/fa8ab3a2-d471-7390-03db-e25d497a99ed HTTP/1.1
> Host: simhost-023b821757dd43606.agni.secondlife.io:12046
> User-Agent: curl/8.6.0
> Accept: */*
> Expect: 100-continue
> Content-Length: 11
> Content-Type: application/x-www-form-urlencoded
>
* Done waiting for 100-continue
* We are completely uploaded and fine
< HTTP/1.1 502 Proxy Error
< Date: Mon, 10 Jun 2024 15:23:55 GMT
< Server: Apache
< X-LL-Request-Id: Zmcai1BarQTtehKeJ6IT6AAAACc
< Content-Length: 341
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request<p>Reason: <strong>Error reading from remote server</strong></p></p>
</body></html>
* Closing connection
curl -v --data "No patience" -H "Expect: 100-continue" 0.00s user 0.01s system 0% cpu 30.094 total
When I try the same thing with a script at Second Life Server 2024-04-13.8669470296, the simulator quickly responds with 'HTTP/1.1 100 Continue' and _then_ with the 200 that the LSL script sends:
% time curl -v --data "stuff " -H "Expect: 100-continue" http://simhost-00f840f841000d8f0.agni.secondlife.io:12046/cap/fb2bfc6f-3518-33f3-6af2-9fa1fb077a98
* Host simhost-00f840f841000d8f0.agni.secondlife.io:12046 was resolved.
* IPv6: (none)
* IPv4: 52.36.129.204
* Trying 52.36.129.204:12046...
* Connected to simhost-00f840f841000d8f0.agni.secondlife.io (52.36.129.204) port 12046
> POST /cap/fb2bfc6f-3518-33f3-6af2-9fa1fb077a98 HTTP/1.1
> Host: simhost-00f840f841000d8f0.agni.secondlife.io:12046
> User-Agent: curl/8.6.0
> Accept: */*
> Expect: 100-continue
> Content-Length: 6
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 200
< Date: Mon, 10 Jun 2024 15:25:39 GMT
< Server: Second Life LSL/Second Life Server 2024-04-13.8669470296 (http://secondlife.com)
< X-LL-Request-Id: Zmca85LUCsyOCPycijIEXAAAAYs
< Content-Length: 17
< Cache-Control: no-cache, max-age=0
< Content-Type: text/plain; charset=utf-8
< Pragma: no-cache
< X-SecondLife-Local-Position: (130.144913, 130.029388, 22.296896)
< X-SecondLife-Local-Rotation: (0.000000, 0.000000, 0.000000, 1.000000)
< X-SecondLife-Local-Velocity: (0.000000, 0.000000, 0.000000)
< X-SecondLife-Object-Key: 4b4e9960-272e-2218-0503-3ad24275cc97
< X-SecondLife-Object-Name: Basic HTTP-in test
< X-SecondLife-Owner-Key: e1a51880-d7b5-4c00-800d-91664f5b84c0
< X-SecondLife-Owner-Name: Maestro Linden
< X-SecondLife-Region: Main Channel Sandbox A (336640, 303360)
< X-SecondLife-Shard: Production
< Connection: close
<
* Closing connection
POST acknowledgedcurl -v --data "stuff " -H "Expect: 100-continue" 0.00s user 0.01s system 5% cpu 0.204 total
Maestro Linden
needs info
Sasun Steinbeck
Maestro Linden Thank you for the info. Having a set of known headers that worked allowed me to find the culprit. Using Curl on my PC worked as well. After sniffing the request headers from my asp.net web request, I discovered that a "Expect" header was being added by the .net framework HTTP library code. This is standard behavior for asp.net, apparently. I tracked down an obscure setting to stop that from happening and that fixed the problem. So it looks like this was a change in the way that "Expect: 100-Continue" headers are handled from the release to the current RC that broke all web requests from asp.net going into SL in a big way. I feel that this is a bad change since your basic, simple http request done in asp.net will never work unless the poor developer figures out this obscure fix somehow. This is going to frustrate future developers to no end. For me, it's fixed, so thank you, but this was definitely something that changed as the "Expect" header currently works (or, just doesn't cause problems) in non-RC regions.
You can probably easily reproduce the problem by adding the Expect header in with curl just like asp.net does, here's what I saw:
curl -v http://simhost-039d5e91e93cab1cd.agni.secondlife.io:12046/cap/24dd5051-882e-8d28-9297-61b9d53276e2 --data "bob" -H "Expect: 100-continue"
* Trying 35.86.162.150:12046...
* Connected to simhost-039d5e91e93cab1cd.agni.secondlife.io (35.86.162.150) port 12046
> POST /cap/24dd5051-882e-8d28-9297-61b9d53276e2 HTTP/1.1
> Host: simhost-039d5e91e93cab1cd.agni.secondlife.io:12046
> User-Agent: curl/8.4.0
> Accept: */*
> Expect: 100-continue
> Content-Length: 3
> Content-Type: application/x-www-form-urlencoded
>
* Done waiting for 100-continue
* We are completely uploaded and fine
< HTTP/1.1 502 Proxy Error
< Date: Sat, 08 Jun 2024 07:48:54 GMT
< Server: Apache
< X-LL-Request-Id: ZmQM5myJciwtp7t163g9dwAAAZQ
< Content-Length: 341
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request<p>Reason: <strong>Error reading from remote server</strong></p></p>
</body></html>
* Closing connection
And that 502 proxy error was exactly what I was seeing in my asp.net code.
Oh and for anyone that has discovered the same problem in their asp.net code, here's the fix, add this to your web.config:
<system.net>
<settings>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
Maestro Linden
I can't reproduce this failure in http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%201/112/166/23 , which is currently running Second Life RC BlueSteel 2024-06-03.9357471418
I set up a basic http-in test script (source below) and made some requests to it with curl, which all return 200s:
# POST attempt
% curl -v http://simhost-039d5e91e93cab1cd.agni.secondlife.io:12046/cap/0e3b237e-a40c-a9d8-309a-1bff054342ed --data "No errors here"
* Host simhost-039d5e91e93cab1cd.agni.secondlife.io:12046 was resolved.
* IPv6: (none)
* IPv4: 35.86.162.150
* Trying 35.86.162.150:12046...
* Connected to simhost-039d5e91e93cab1cd.agni.secondlife.io (35.86.162.150) port 12046
> POST /cap/0e3b237e-a40c-a9d8-309a-1bff054342ed HTTP/1.1
> Host: simhost-039d5e91e93cab1cd.agni.secondlife.io:12046
> User-Agent: curl/8.6.0
> Accept: */*
> Content-Length: 14
> Content-Type: application/x-www-form-urlencoded
>
< HTTP/1.1 200
< Date: Fri, 07 Jun 2024 23:37:28 GMT
< Server: Second Life LSL/Second Life RC BlueSteel 2024-06-03.9357471418 (http://secondlife.com)
< X-LL-Request-Id: ZmOZuK-qhUv_l24NjOeiWQAAABw
< Content-Length: 17
< Cache-Control: no-cache, max-age=0
< Content-Type: text/plain; charset=utf-8
< Pragma: no-cache
< X-SecondLife-Local-Position: (109.308586, 167.238617, 22.296896)
< X-SecondLife-Local-Rotation: (0.000000, 0.000000, 0.000000, 1.000000)
< X-SecondLife-Local-Velocity: (0.000000, 0.000000, 0.000000)
< X-SecondLife-Object-Key: df14ad71-1a21-fe08-9a52-b34edf5bb2a6
< X-SecondLife-Object-Name: HTTP-in test
< X-SecondLife-Owner-Key: e1a51880-d7b5-4c00-800d-91664f5b84c0
< X-SecondLife-Owner-Name: Maestro Linden
< X-SecondLife-Region: BlueSteel Sandbox 1 (336640, 305664)
< X-SecondLife-Shard: Production
< Connection: close
<
* Closing connection
POST acknowledged%
# GET attempt
% curl -v http://simhost-039d5e91e93cab1cd.agni.secondlife.io:12046/cap/0e3b237e-a40c-a9d8-309a-1bff054342ed
* Host simhost-039d5e91e93cab1cd.agni.secondlife.io:12046 was resolved.
* IPv6: (none)
* IPv4: 35.86.162.150
* Trying 35.86.162.150:12046...
* Connected to simhost-039d5e91e93cab1cd.agni.secondlife.io (35.86.162.150) port 12046
> GET /cap/0e3b237e-a40c-a9d8-309a-1bff054342ed HTTP/1.1
> Host: simhost-039d5e91e93cab1cd.agni.secondlife.io:12046
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200
< Date: Fri, 07 Jun 2024 23:38:49 GMT
< Server: Second Life LSL/Second Life RC BlueSteel 2024-06-03.9357471418 (http://secondlife.com)
< X-LL-Request-Id: ZmOaCa-qhUv_l24NjOejKAAAACo
< Content-Length: 12
< Cache-Control: no-cache, max-age=0
< Content-Type: text/plain; charset=utf-8
< Pragma: no-cache
< X-SecondLife-Local-Position: (109.308586, 167.238617, 22.296896)
< X-SecondLife-Local-Rotation: (0.000000, 0.000000, 0.000000, 1.000000)
< X-SecondLife-Local-Velocity: (0.000000, 0.000000, 0.000000)
< X-SecondLife-Object-Key: df14ad71-1a21-fe08-9a52-b34edf5bb2a6
< X-SecondLife-Object-Name: HTTP-in test
< X-SecondLife-Owner-Key: e1a51880-d7b5-4c00-800d-91664f5b84c0
< X-SecondLife-Owner-Name: Maestro Linden
< X-SecondLife-Region: BlueSteel Sandbox 1 (336640, 305664)
< X-SecondLife-Shard: Production
< Connection: close
<
* Closing connection
Hello there!%
The in-world chat output was:
HTTP-in test: 2024-06-07T23:37:28.261991Z Got a POST request from user-agent: 'curl/8.6.0' with body 'No errors here'
HTTP-in test: 2024-06-07T23:38:49.774415Z Got a GET request from user-agent: 'curl/8.6.0'
You _will_ see a 502 if your http-in script neglects to respond to a request in a timely fashion. For example, if you uncomment the
llSleep(100)
in my script so that it waits 100 seconds before responding, the client will see a 502 Proxy Error
approximately 30 seconds into the request. I see the same timeout period on any simulator version.default
{
state_entry()
{
llOwnerSay("Requesting HTTP-in URL in " + llGetEnv("sim_channel")
+ " " + llGetEnv("sim_version"));
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_DENIED)
{
llOwnerSay("Got URL_REQUEST_DENIED - No free URLs!");
}
else if (method == URL_REQUEST_GRANTED)
{
llOwnerSay("Got URL_REQUEST_GRANTED. Send your requests to " + body);
}
else if (method == "GET")
{
llOwnerSay(llGetTimestamp() + " Got a GET request from user-agent: '"
+ llGetHTTPHeader(id, "user-agent") + "'");
llHTTPResponse(id, 200, "Hello there!");
}
else if (method == "POST")
{
llOwnerSay(llGetTimestamp() + " Got a POST request from user-agent: '"
+ llGetHTTPHeader(id, "user-agent") + "' with body '" + body + "'");
// putting in a really long sleep before sending the response will cause a timeout
// llSleep(100);
llHTTPResponse(id, 200, "POST acknowledged");
}
}
}
If you're still seeing this issue, please include a repro script.
Load More
→