llHTTPRequest changes

[Xiija]

just a heads up on another change to http coming soon,

posted by Rider Linden in this thread ...

https://community.secondlife.com/forums/topic/409237-change-transparency-of-prims-with-the-use-of-audio-stream/

 

Quote

You will want to fix this line.  "text/application/xml" is not a valid mime type and in a roll coming very soon we will be validating this value for formatting.  A valid value will be in the form "type/subtype[;charset=utf-8".  The examples on the wiki were incorrect but have been updated.

 

[777gr]

How to fix all requests without editing other scripts
FIX 499 ERROR

Create an object with the script shown below;

string yourDomain		=	"http://example.com/";		// Your main host domain (could also be an IP)
string hostUserAgent		=	"Mozilla/5.0";			// Your host's PHP Variable: _SERVER["HTTP_USER_AGENT"]
default
{
    state_entry()
    {
        llSetTimerEvent(3600);
    }
    touch_start(integer a)
    {
      	if(llDetectedKey(0)==llGetOwner()){llHTTPRequest(yourDomain,[HTTP_METHOD,"GET",HTTP_USER_AGENT,hostUserAgent],"");}
    }
    timer()
    {
        llHTTPRequest(yourDomain,[HTTP_METHOD,"GET",HTTP_USER_AGENT,hostUserAgent],"");
    }
    http_response(key id,integer status,list meta,string data)
    {
      	/*
        llRegionSay(DEBUG_CHANNEL,"CODE:"+(string)status);
        llRegionSay(DEBUG_CHANNEL,"DATA:"+data);
    	*/
    }
}

Keep in mind when your host's user agent as example is
'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0'
Then the string hostUserAgent is 'Mozilla/5.0'

As weird as it seems to look: By executing a valid request every x minutes/hours your host keeps the connection alive for quite a while.

Dexter Morgan (777gr)

Edited August 3, 2017 by 777gr

[Oz Linden]

59 minutes ago, 777gr said:

Keep in mind when your host's user agent as example is
'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0'
Then the string hostUserAgent is 'Mozilla/5.0'

As weird as it seems to look: By executing a valid request every x minutes/hours your host keeps the connection alive for quite a while.

Dexter Morgan (777gr)

The User-Agent value identifies the HTTP client, not the host (there is a 'Server' header that identifies the server). It's rarely true that you need to manipulate the user agent value unless the server you're accessing limits or modifies responses based on it.

Please do not execute a request periodically just to keep a connection open... you're consuming simulator resources. Opening a connection is pretty inexpensive.

[777gr]

1 minute ago, Oz Linden said:

The User-Agent value identifies the HTTP client, not the host (there is a 'Server' header that identifies the server). It's rarely true that you need to manipulate the user agent value unless the server you're accessing limits or modifies responses based on it.

Please do not execute a request periodically just to keep a connection open... you're consuming simulator resources. Opening a connection is pretty inexpensive.

I do not see another solution at the moment.

[Oz Linden]

23 minutes ago, 777gr said:

I do not see another solution at the moment.

Solution to what?

[777gr]

Just now, Oz Linden said:

Solution to what?

Since the changes of llHTTPRequest, 1st I cannot use any SSL/https URL's without the LSL user agent, second of all since the update 95% of the day it returns error code 499 Client Closed Request to any page of my server. I have contacted my hosting provider (GoDaddy) and the LL support, and all points to the recent changes in llHTTPRequest.
This is a working temporary fix until we know what to do.
(Yes my server does allow the user agent Second-Life-LSL)

[Oz Linden]

7 minutes ago, 777gr said:

Since the changes of llHTTPRequest, 1st I cannot use any SSL/https URL's without the LSL user agent, second of all since the update 95% of the day it returns error code 499 Client Closed Request to any page of my server. I have contacted my hosting provider (GoDaddy) and the LL support, and all points to the recent changes in llHTTPRequest.
This is a working temporary fix until we know what to do.
(Yes my server does allow the user agent Second-Life-LSL)

Please file a Jira with the specifics for your LSL script and server.

[Necati Millet]

There are many that are getting affected by the 499 problem.

[Whirly Fizzle]

3 hours ago, Oz Linden said:

Please file a Jira with the specifics for your LSL script and server.

Likely to be the same problem as BUG-134072 -  HTTP error code:499, request and response keys aren't matching on random regions

[Arron Rainfall]

Are there any plans for LL to stop using self-signed certificates with URLs obtained by llRequestSecureURL?

[Oz Linden]

16 hours ago, Arron Rainfall said:

Are there any plans for LL to stop using self-signed certificates with URLs obtained by llRequestSecureURL?

They are not self-signed certificates. They are signed by the Linden Lab Certificate Authority, the public certificate for which is available at

https://bitbucket.org/lindenlab/llca/raw/tip/LindenLab.crt

you should be able to install that certificate to provide robust authentication of the script request.

We do not currently have any plans to change that.

[Arron Rainfall]

5 hours ago, Oz Linden said:

They are not self-signed certificates. They are signed by the Linden Lab Certificate Authority, the public certificate for which is available at

https://bitbucket.org/lindenlab/llca/raw/tip/LindenLab.crt

you should be able to install that certificate to provide robust authentication of the script request.

We do not currently have any plans to change that.

I stand corrected, but what if we would like to use 3rd party services such as AWS SNS to deliver data to our scripts? AWS SNS delivers fine to HTTP urls inworld, but fails to deliver data to HTTPS urls.

http://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.https.ca.html

That page states "Amazon SNS will only deliver messages to HTTPS endpoints that have a signed certificate from a trusted CA that Amazon SNS recognizes".

It also includes a list of all CAs that AWS recognizes. Here is my Cloud Watch entry.

[Oz Linden]

1 hour ago, Arron Rainfall said:

I stand corrected, but what if we would like to use 3rd party services such as AWS SNS to deliver data to our scripts? AWS SNS delivers fine to HTTP urls inworld, but fails to deliver data to HTTPS urls.

http://docs.aws.amazon.com/sns/latest/dg/SendMessageToHttp.https.ca.html

That page states "Amazon SNS will only deliver messages to HTTPS endpoints that have a signed certificate from a trusted CA that Amazon SNS recognizes".

It also includes a list of all CAs that AWS recognizes.

For the time being at least, I don't have a solution to suggest.

We have a lot of simulator hosts, and they come and go very frequently. I'm not aware of a certificate authority that provides the availability and scale we would need at a cost we could afford to provide a server certificate for each simulator host (if you find one, by all means, file a Feature Request... we'll look at it). Using wildcard certificates would seem to me to be a solution that's less secure than the problem.

In the long run, I'm sure that either we'll find a way or services like SNS will allow you to provide trusted root CAs to add to their built-in list, but at present that's not something I can make any predictions about.

[Dracony225]

9 minutes ago, Oz Linden said:

For the time being at least, I don't have a solution to suggest.

We have a lot of simulator hosts, and they come and go very frequently. I'm not aware of a certificate authority that provides the availability and scale we would need at a cost we could afford to provide a server certificate for each simulator host (if you find one, by all means, file a Feature Request... we'll look at it). Using wildcard certificates would seem to me to be a solution that's less secure than the problem.

In the long run, I'm sure that either we'll find a way or services like SNS will allow you to provide trusted root CAs to add to their built-in list, but at present that's not something I can make any predictions about.

The server certificate currently used by all simulator hosts is a wildcard certificate, signed to *.agni.lindenlab.com. Linden Lab can purchase wildcard certificates for a relatively cheap price per year (I've seen one from a retailer for $114 for 3 years). Either way, it is impractical for users to add your CA to their browsers in order to utilize basic HTTPS communication, as many would not know how to do this if it requires the end-user to install the certificate before communication is permitted by the browser. The Amazon issue is a bigger problem, as we don't have direct influence over Amazon or their trust in CA certificates.

[Arron Rainfall]

20 minutes ago, Oz Linden said:

For the time being at least, I don't have a solution to suggest.

We have a lot of simulator hosts, and they come and go very frequently. I'm not aware of a certificate authority that provides the availability and scale we would need at a cost we could afford to provide a server certificate for each simulator host (if you find one, by all means, file a Feature Request... we'll look at it). Using wildcard certificates would seem to me to be a solution that's less secure than the problem.

In the long run, I'm sure that either we'll find a way or services like SNS will allow you to provide trusted root CAs to add to their built-in list, but at present that's not something I can make any predictions about.

I think LL might want to take a look at Let's Encrypt. They are free and they will be issuing wildcard certificates in January:

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

[Crai Conundrum]

Just now, Arron Rainfall said:

I think LL might want to take a look at Let's Encrypt. They are free and they will be issuing wildcard certificates in January:

https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

This is true, but the one main issue with that is LL would have to re-issue the certificate every 3 months... which would then be impractical for them. Unless they have auto-renewal setup on their server.

[Arron Rainfall]

8 minutes ago, absolutelycrazy said:

This is true, but the one main issue with that is LL would have to re-issue the certificate every 3 months... which would then be impractical for them. Unless they have auto-renewal setup on their server.

That's true. You do need to setup auto-renewal with Let's Encrypt. I figured it wouldn't hurt to throw that in there though.

[TommyTheTerrible]

I think something like Let's Encrypt is a great idea but I don't understand why Linden Labs just can't setup their own certificate service and then register as a CA with AWS.

You guys charge an insane amount of money for sims, no reason why we can't expect you to make them secure.

[Crai Conundrum]

4 minutes ago, TommyTheTerrible said:

I think something like Let's Encrypt is a great idea but I don't understand why Linden Labs just can't setup their own certificate service and then register as a CA with AWS.

You guys charge an insane amount of money for sims, no reason why we can't expect you to make them secure.

No need for them to make their own CA (which is what they currently have done with the "Linden Lab Certificate Authority" root they are using). All they have to do is purchase a cheap domain validated wildcard certificate. Besides, most CAs issue certificates with 2048-bit RSA keys nowadays, so the encryption is the same as what they currently have as far as I'm aware. They'd get all browsers and services to trust them then with a trusted CA.

[Arron Rainfall]

9 minutes ago, TommyTheTerrible said:

I think something like Let's Encrypt is a great idea but I don't understand why Linden Labs just can't setup their own certificate service and then register as a CA with AWS.

You guys charge an insane amount of money for sims, no reason why we can't expect you to make them secure.

Linden Lab really should purchase a wildcard certificate from a trusted CA. It shouldn't matter even if the wildcard certificate was $500/year(even though you can get them cheaper than that). They got thousands of sims that rich people are paying $300+/month for. There's no reason they couldn't afford a wildcard certificate. They've made it obvious, by not providing any new functions that are considered intuitive and highly demanded(*cough* Name2Key *cough*), that they want the creators of Second Life to take some of the overhead of functionality and putting it on their own servers. The least they can do is use a wildcard certificate issued by a trusted CA so creators can use 3rd party services like AWS SNS or AWS Lambda to deliver data to inworld HTTPS URLs.

Linden Lab already has a business relationship with Amazon: https://aws.amazon.com/solutions/case-studies/linden-lab/

Given this intormation, if Linden Labs absolutely refused to purchase a wildcard certificate, then perhaps they could try to persuade Amazon to recognize Linden Lab Certificate Authority as a trusted CA.

[Crai Conundrum]

12 minutes ago, Arron Rainfall said:

Linden Lab really should purchase a wildcard certificate from a trusted CA. It shouldn't matter even if the wildcard certificate was $500/year(even though you can get them cheaper than that). They got thousands of sims that rich people are paying $300+/month for. There's no reason they couldn't afford a wildcard certificate. They've made it obvious, by not providing any new functions that are considered intuitive and highly demanded(*cough* Name2Key *cough*), that they want the creators of Second Life to take some of the overhead of functionality and putting it on their own servers. The least they can do is use a wildcard certificate issued by a trusted CA so creators can use 3rd party services like AWS SNS or AWS Lambda to deliver data to inworld HTTPS URLs.

Linden Lab already has a business relationship with Amazon: https://aws.amazon.com/solutions/case-studies/linden-lab/

Given this intormation, if Linden Labs absolutely refused to purchase a wildcard certificate, then perhaps they could try to persuade Amazon to recognize Linden Lab Certificate Authority as a trusted CA.

Agreed. However, if they only take the Amazon route here, they will not be accounting for those who write web applications with JavaScript, which requires the browser's trust in order to execute (Google Chrome actively blocks XMLHttpRequest attempts with a non-trusted CA root certificate). It will also not resolve other services and applications that require a valid CA root.

Paying for a wildcard certificate seems to be the simplest and most secure action Linden Lab could take here. If I were them, I'd do it without a second thought.

Edited September 21, 2017 by absolutelycrazy

[Ruthven Ravenhurst]

I'm trying to use the script at http://wiki.secondlife.com/wiki/Permanent_Primitive_URL to establish a permanent url to communicate between objects on different sims. It worked for me when I tested it a while back, but now it's not. Is it a result of this change? How do I fix it? This is the error message i get {"errorCode":1206,"errorMessage":"URL you tried to shorten was invalid.","results":"","statusCode":"ERROR"}

[Love Zhaoying]

11 hours ago, Ruthven Willenov said:

I'm trying to use the script at http://wiki.secondlife.com/wiki/Permanent_Primitive_URL to establish a permanent url to communicate between objects on different sims. It worked for me when I tested it a while back, but now it's not. Is it a result of this change? How do I fix it? This is the error message i get {"errorCode":1206,"errorMessage":"URL you tried to shorten was invalid.","results":"","statusCode":"ERROR"}

I would suggest echoing the URL you are using (what you got from the llRequestURL() response) via llOwnerSay() in case you really are passing an invalid URL to the tinyurl.com request.

[Ruthven Ravenhurst]

7 minutes ago, Love Zhaoying said:

I would suggest echoing the URL you are using (what you got from the llRequestURL() response) via llOwnerSay() in case you really are passing an invalid URL to the tinyurl.com request.

Yes, I took the URL it gave me and tried it directly on the tiny website, and it also told me it was invalid. Then tried it on Google url shortener and noticed it removed the port number that SL generated in the URL. So to fix it, what I did was parsed that out, then passed it to tinycc via the script, and it worked.

[Love Zhaoying]

6 minutes ago, Ruthven Willenov said:

Yes, I took the URL it gave me and tried it directly on the tiny website, and it also told me it was invalid. Then tried it on Google url shortener and noticed it removed the port number that SL generated in the URL. So to fix it, what I did was parsed that out, then passed it to tinycc via the script, and it worked.

Good job!