Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-228850] HTTP requests to known-working external URLs always fail with HTTP response 499 #6836

Closed
2 tasks
sl-service-account opened this issue May 31, 2020 · 7 comments
Closed
2 tasks

[BUG-228850] HTTP requests to known-working external URLs always fail with HTTP response 499 #6836

sl-service-account opened this issue May 31, 2020 · 7 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

sl-service-account commented May 31, 2020 •
edited by sl-issues-importer bot

What just happened?

Using llHTTPRequest() to connect to several endpoints in my domain now returns response code 499 for every request. Endpoints are accurate and functioning; most of these endpoints have been in use for several years, and started returning 499 errors the week of 25 May 2020.

As an example, this URL:

https://lounetizen.com/api/book/cover/?isbn=0140267972

Should returning some parsable plaintext information about the book "Desert Places" by Robyn Davidson. And, outside SL, it does just that. Requested from an LSL script, it returns error 499. That endpoint supports a product that has been available for three years.

Status 499 is returned with either HTTP or HTTPS versions of the URL.

Numerous other (but apparently not all) endpoints in my domain also return 499 errors in all cases. None of the endpoints returning 499s are high traffic. The issue can be reproduced on regions I have never previously visited, so it cannot be HTTP throttling.

What were you doing when it happened?

I received a report from a user of one of my products that it had stopped working. So I started checking others.

What were you expecting to happen instead?

I was expecting requests to my domain from llHTTPRequest to be honoured as they have been previously.

Other information

This issue breaks existing content.

Sample object available on request.

Links

Related

Duplicates

Original Jira Fields
Field Value
Issue BUG-228850
Summary HTTP requests to known-working external URLs always fail with HTTP response 499
Type Bug
Priority Unset
Status Closed
Resolution Duplicate
Reporter Lou Netizen (lou.netizen)
Created at 2020-05-31T22:27:15Z
Updated at 2020-06-02T17:05:32Z 
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2020-05-31T21:02:22.816-0500',
  "Is there anything you'd like to add?": 'This issue breaks existing content.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'Using llHTTPRequest() to connect to severael endpoints in my domain now returns response code 499 for every request. Endpoints are accurate and functioning; most of these endpoints have been in use for several years, and started returning 499 errors the week of 25 May 2020.\r\n\r\nAs an example, this URL:\r\n\r\nview-source:https://lounetizen.com/api/book/cover/?isbn=0140267972\r\n\r\nShould returning some parsable plaintext information about the book "Desert Places" by Robyn Davidson. And, outside SL, it does just that. Requested from an LSL script, it returns error 499. That endpoint supports a product that has been available for three years.\r\n\r\nNumerous other (but apparently not all) endpoints in my domain also return 499 errors in all cases. None of the endpoints returning 499s are high traffic.',
  'What were you doing when it happened?': 'I received a report from a user of one of my products that it had stopped working. So I started checking others.',
  'What were you expecting to happen instead?': 'I was expecting requests to my domain from llHTTPRequest to be honoured as they have been previously.',
}
@sl-service-account
Copy link
Author

animats commented at 2020-06-01T02:02:23Z

Also seeing this.  Results vary with the domain:

https://www.example.com - OK

http://animats.dreamhosters.com - OK (301, moved permanently to the HTTPS url)

https://animats.dreamhosters.com - error 499

Probable cause: one root cert of Usertrust expired May 30th. Ref:

https://www.ssl.com/faqs/i-noticed-that-the-addtrust-external-ca-root-is-expiring-soon-will-i-be-affected/

 

"The short answer is the overwhelming majority of people will not experience any problems when the AddTrust root expires in May. The AddTrust cross-signing was originally done to account for older devices that did not include the USERTrust root. If the USERTrust root is present (as it is in 100% of modern browsers, operating systems, and mobile devices), the software will simply choose a trust path that leads to USERTrust and ignores AddTrust. Due to the USERTrust root’s ubiquity, only a vanishingly small number of legacy devices can be expected to experience trust issues when AddTrust expires."

@sl-service-account
Copy link
Author

Lou Netizen commented at 2020-06-01T06:33:51Z

I don't have any special insight into how regions manage HTTP connections, but it is unclear how the expiry of the AddTrust root certificate could:

  • Impact both HTTP and HTTPS URLs

  • Impact some URLs for a domain and not others.

    As stated above, numerous — but not all — endpoints on my domain are inaccessible from llHTTPRequest. The ones that return 499 are inaccessible via either HTTP and HTTPS.

@sl-service-account
Copy link
Author

animats commented at 2020-06-01T06:48:53Z

See also BUG-228848.

Do you have a non-HTTP URL that fails? Does it redirect to an HTTPS URL?

 

@sl-service-account
Copy link
Author

Lou Netizen commented at 2020-06-01T21:02:12Z, updated at 2020-06-01T22:16:06Z

http://lounetizen.com/api/simple-echo/ was failing last night and still seems to be failing tonight, since its log has no new entries and I left a script pinging it every five minutes. It just returns "ok" whether accessed via HTTP or HTTPS. It does not redirect to HTTPS.

All other endpoints on that site currently use HTTPS. Some are functioning normally from a wide variety of regions with a wide variety of object owners; other are failing from a similarly-wide variety of regions and owners.

@sl-service-account
Copy link
Author

animats commented at 2020-06-01T22:32:39Z

I tried that, and your server just returns "ok", with a status of 200. That's normal.

@sl-service-account
Copy link
Author

Lou Netizen commented at 2020-06-01T22:40:55Z

I agree getting status 200 and "ok" is the expected behaviour there. However, the script I left running inworld still apparently cannot reach it (or, at least, no accesses are being logged) and it's still reporting 499s every five minutes to another service which is still working. I'll see if I can get inworld tonight and check on it.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2020-06-02T10:35:01Z

Looks likely a fix is coming on Tusday - see this post: https://community.secondlife.com/forums/topic/455707-deploy-plan-for-the-week-of-2020-06-01/

@sl-issues-importer sl-issues-importer bot mentioned this issue Feb 14, 2024
Closed
3 tasks
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