Skip to content
This repository was archived by the owner on Apr 4, 2025. It is now read-only.

[BUG-216320] Error when retrieving grid statistics page via llHTTPRequest #3720

Closed
5 tasks
sl-service-account opened this issue May 23, 2018 · 10 comments
Closed
5 tasks

[BUG-216320] Error when retrieving grid statistics page via llHTTPRequest #3720

sl-service-account opened this issue May 23, 2018 · 10 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

sl-service-account commented May 23, 2018 •
edited by sl-issues-importer bot
Loading

Steps to Reproduce

Put this script in a prim:

key gRequest;

default
{
    state_entry()
    {
        gRequest = llHTTPRequest("http://secondlife.com/httprequest/homepage.php", [], "");
    }

    http_response(key request_id, integer status, list metadata, string body)
    {
        if (request_id == gRequest)
        {
            llOwnerSay("status: " + (string)status + ", body: '" + body + "', " + " metadata: '" + llList2CSV(metadata) + "'");
        }
    }
}

Actual Behavior

llHTTPRequest("http://secondlife.com/httprequest/homepage.php", [], "") returns an empty body and http status 499.

Requests from outside the grid to the same url are successful (returning 302 redirect via http, or the actual data with a status 200 when via https.)

Expected Behavior

Expected result of llHTTPRequest("http://secondlife.com/httprequest/homepage.php", [], ""); is an http status 200 and a body of an http response with statistical data, as can be seen when visiting this url with a browser: http://secondlife.com/httprequest/homepage.php.

Other information

Attachments

Links

Duplicates

Related

Original Jira Fields
Field Value
Issue BUG-216320
Summary Error when retrieving grid statistics page via llHTTPRequest
Type Bug
Priority Unset
Status Closed
Resolution Accepted
Reporter Thickbrick Sleaford (thickbrick.sleaford)
Created at 2018-05-23T08:47:16Z
Updated at 2021-02-12T15:00:25Z 
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2018-05-23T10:14:07.393-0500',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'My script, which has been retrieving data for the last decade from http://secondlife.com/httprequest/homepage.php now fails with a 499 error.\r\n\r\nDoing an llHTTPRequest to that url, via http or https results in a status 499 (unspecified internal error) while requests from outside the grid to the same url are successful (returning 302 redirect via http, or the actual data with a status 200 when via https.)',
  'What were you doing when it happened?': 'nothing; script has been running for a decade or so.',
  'What were you expecting to happen instead?': 'Expected result of llHTTPRequest("http://secondlife.com/httprequest/homepage.php", [], ""); is a body of an http response with statistical data, as can be seen when visiting that url via a browser, and http status 200.',
  'Where': 'http://secondlife.com/httprequest/homepage.php',
}
@sl-service-account
Copy link
Author

Chaser Zaks commented at 2018-05-23T15:14:07Z

Has this worked before? If not, I believe this is expected behavior for security reasons.
From what I recall, the squidproxy gateway will block all requests to these addresses:

  • 0.0.0.0
  • 10.0.0.0/8
  • 127.0.0.1
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 255.255.255.255
  • fd00::/8
  • secondlife.com
  • *.secondlife.com
  • lindenlab.com
  • *.lindenlab.com (With the exception to *.aditi.lindenlab.com and *.agni.lindenlab.com)

Of which, secondlife.com is in that list.

@sl-service-account
Copy link
Author

Thickbrick Sleaford commented at 2018-05-23T16:36:55Z

Yes, the script that I'm using this in has been working unmodified since approx. 2008. I did recompile it to mono at some point, but I didn't change anything in the last few years. Could it be that the 302 redirect from http to https is what has changed now, and is triggering the proxy blacklist?

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2018-05-30T18:58:13Z, updated at 2018-05-30T19:00:32Z

Also affects: https://secondlife.com/xmlhttp/secondlife.php

kRequest = llHTTPRequest("http://secondlife.com/xmlhttp/secondlife.php", [], "");

@sl-service-account
Copy link
Author

Nalates Urriah commented at 2018-06-26T23:57:24Z

I just noticed that my logging script is hitting 499 errors too.

The working part of the script is as above. Like Whirly, I find secondlife.com/httprequest/homepage.php and secondlife.com/xmlhttp/secondlife.php both give a 499 error.

Using http or https makes no difference.

Help!

@sl-service-account
Copy link
Author

Kyle Linden commented at 2018-06-27T15:56:23Z

URLs function in all browsers. This looks like an lsl http issue not a web issue.

@sl-service-account
Copy link
Author

Oz Linden commented at 2018-10-29T18:10:16Z

This should be working now.

@sl-service-account
Copy link
Author

Mister Acacia commented at 2018-10-29T19:31:18Z

Just now tested, it does appear to be working.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2018-10-31T17:09:29Z

Still broken for https://secondlife.com/xmlhttp/secondlife.php
Ref: BUG-225726

@sl-service-account
Copy link
Author

Natty Linden commented at 2018-10-31T17:49:52Z

Hi, Whirly! The script in this ticket & Lou's in BUG-225726 appear to work for me using the original http: URLs, which is currently the intended behavior. Thanks for noting the issue with the https: addresses.

@sl-service-account
Copy link
Author

Oz Linden commented at 2021-02-12T15:00:25Z

This is working now when I use the script in the included Description

This was referenced Feb 14, 2024
Closed
Closed
Closed
Closed
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
project:BUG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sl-service-account