HTTP ERRORS, Status = 403, HTTPbody "Access denied".

[AnnMarie Otoole]

HTTP ERRORS, Status = 403,  HTTPbody "Access denied".

I'm getting this error code all over SL.  All my vendors, licenced objects, vehicles etc are shut down.

I've filed a bug and can demonstrate it with a simple 4 line LSL program.

Is anybody else experiencing this problem?  If so please contact Maestro Linden.

[Darkie Minotaur]

Just to state the obvious:

Are you sure it's not a server issue? 403 usually indicates anything from file permission, over .htaccess settings to problems with the application pooling.

Have you tested to rule such server issues out?

[AnnMarie Otoole]

Yes, thanks for the response.

Similar queries issued from a browser query work fine and if I disable the .php processor the HTTP is querying, I get a 404 not found response so the destination HTTP server is working but data is being blocked coming back into SL.

[Darkie Minotaur]

One frequent issue with shred hosting plans is, thatrequests from a certain source get blocked if the number or frequency of requests run against certain limits that the hosting provider established.

You may try to file a ticket there as well.

[AnnMarie Otoole]

If anyone is interested I've identified the problem.

LL has started blocking HTTP destinations.  It is perhaps a throttle process to prevent overload although most, if not all of my blocked addresses are very low volume.  But once an HTTP address is on the throttle list it stays there.

The FIX.

Change the HTTP request address in your LSL script and the destination .php (or other) program name to suit.

[161488303349]

---

AnnMarie Otoole wrote:

If anyone is interested I've identified the problem.

LL has started blocking HTTP destinations.  It is perhaps a throttle process to prevent overload although most, if not all of my blocked addresses are very low volume.  But once an HTTP address is on the throttle list it stays there.

The FIX.

Change the HTTP request address in your LSL script and the destination .php (or other) program name to suit.

---

the fix would be to file a ticket and ask to be removed. what you suggesting is a hack

[Phil Deakins]

I agree, 16. If LL put a destination on the list, then there was a reason for it. Circumventing it is no different to someone circumventing a ban by creating and using an alt. 

[Freya Mokusei]

---

Phil Deakins wrote:

If LL put a destination on the list, then there was a reason for it. Circumventing it is no different to someone circumventing a ban by creating and using an alt. 

---

I disagree with this. If LL wanted to block HTTP resolution there are ways to do it without creating a 'block list' of targets. Testing against a block list at all is a fairly poor method of preventing HTTP from completing (it's slow, specific, and time-consuming to search). Moving the destination is the inevitable consequence of this block, especially without any guidance/repremand from the Lab.

Any significant block to HTTP traffic would have to occur on a by-domain basis, not by-file. There is nothing in the ToS that warns against this, and it's impossible to use llHTTPRequest in a way that negatively affects any user, server or service. Any disciplinary action should absolutely be accompanied by contact from LL, anything else can be routed around.

ETA: This is a 'do at your own risk' kinda thing, obviously. Experience tells me that if you're doing anything you shouldn't without being able to see the consequences, a Labby will get in touch sooner or later.

[Phil Deakins]

If what AnnMarie said is true, then circumventing it is no different to a banned person circumventing the ban by creating and using an alt.

[Freya Mokusei]

---

Phil Deakins wrote:

If what AnnMarie said is true, then circumventing it is no different to a banned person circumventing the ban by creating and using an alt.

---

If what AMO said is true, it's very different:-

• Suspensions/bans give Emailed notification (with stated explanation).
• Suspensions/bans give chances to appeal.
• Suspensions/bans prevent access to the SL service, returning an error code (You are unable to login etc).
• Circumventing a ban is in the Terms of Service.

There's no point putting things on hold because a some low-level engineer has a grudge, because hardware has failed, or because of a bug. If they have an issue with AMO's use of llHTTPRequest, they need to tell her, in writing (and more importantly, inform the SL userbase that this is a risk of using llHTTPRequest. LSL is hacky enough already). The best reason for AMO to keep doing what she's doing is simply that she has no idea if she's done anything wrong; she has no way to improve her scripts or HTTP-actions without knowing what caused this block to happen.

----

There's also no reason to return a status code 403 for this error; it's not being caused by the server. From Wikipedia:-

"The request was a valid request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference. On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g. a recognized user attempting to access restricted content)."

-----

Many people use llHTTPRequest every day, it's absolutely necessary. Any changes to its functions need to be documented by LL. It is far more dangerous that scripters assume their scripts may be blocked, and hack around this by using distributed or redundant HTTP-referrals (especially if AMO is not correct in the cause).

[Qie Niangao]

---

Many people use llHTTPRequest every day, it's absolutely necessary. Any changes to its functions need to be documented by LL.

---

And this is what worries me. I have a few systems that depend on steady flow of http traffic. The Lindens have let it be known that major changes to http capacity available to scripts are coming, although the details are still being worked out. We can go to test regions to experience the errors we should anticipate, but it's impossible to know at this time whether http communications will still be viable at all, as it appears scripts will be competing for the same restricted bandwidth pool as images (current texture diffusemaps as well as the potential tripling in download demand to be expected after normalmaps and specularmaps are added), plus Inventory, plus all other services LL will eventually migrate to http.

Oh, yeah: They'll also be competing with any other http-using scripts momentarily passing through the region. At least as best I can make sense of the plan.

If this is really what's coming, then getting around 403 errors may be at best a temporary workaround... kludge... hack... whatever term one chooses for it.

[Phil Deakins]

Alright, I'll put it another way...

If LL has added AnnMarie's HTTP destinations to a list of ones to disallow, then AnnMarie circumventing it is no different to someone circumventing a ban by creating an alt and continuing to use SL. That's an undisputable fact.

LL doesn't have to give reasons to any individual. The addition of AnnMarie's HTTP destinations to the list (if the list actually exists, and if that's what happened) may well be programmatic, in which case a personal explanation would be unlikely. Either way, the lack of a personal explanation from LL is irrelevant.

[Perrie Juran]

---

AnnMarie Otoole wrote:

 

Is anybody else experiencing this problem?  If so please contact Maestro Linden.

---

Did Maestro ask you to file this request for him?

I didn't see any requests from him about this in the Server Forum where he normally posts.

Though I may have missed it.

[Freya Mokusei]

---

Phil Deakins wrote:

That's an undisputable fact.

---

It is not fact by any stretch of the imagination, your analogy makes no sense. Disciplinary procedures are entirely separate to having script behaviour curtailed in this fashion, especially without warning. See the explanation in my previous post.

Further, yeah, LL are expected to give an explanation to disciplinary proceedings. It's part of the ToS, a part to which they generally hold themselves accountable. And this programmatic system you're describing doesn't exist; you would need a phenominally high volume of llHTTPRequests per object per sim in order to attract any attention - there is no automatic function that would cause scripts stop receiving data via HTTP grid-wide (because that would be crazy).

This will be my last response to you in this thread, as you're clearly misrepresenting reality (or misunderstanding it).

 

 

[AnnMarie Otoole]

Thanks for all the EXPERT opinions but you don't have a clue what I'm talking about.  If you are not actually using this SL HTTP feature go back to pixel sex or whatever your an expert at.

I reported it on a JIRA when it first happened.  I've been working with Maestro Linden on the problem.  I've given him objects demonstrating the bug.  With 80% of my products shut down and customers from all over SL contacting me about it, I worked all weekend on it to get things working.  It took 2 days to narrow it down to SL blocking some addresses.

Most of the HTTP links have been running for 4 years or more in SL and none of them excessive.  They occurred on multiple URL addresses, accessing multiple data bases, multiple sims,.multiple owners and all server types.  It happened (more or less) simultaneourlsy across SL about the time of the last roll out, Wednesday I think.  The majority of my traffic is the vehicles I run that do an http acces to a data base on each sim crossing, about once a minute +/-.    The LSL throttle is set at 25 HTTP requests in 20 seconds maximum and there is no penalty for exceeding it, you just don't get through so this was a BUG, not a penalty.

Tests from non SL sources did not show the problem so that narrowed it down to the SL/Internet interface.  Further experimenting showed it was outgoing HTTP that was being blocked and an error message returned, rather than blocking incoming responses from the data base.  SO FAR changing the URL address by adding a single digit to it has been working with no problems.

[Freya Mokusei]

---

AnnMarie Otoole wrote:

The majority of my traffic is the vehicles I run that do an http acces to a data base on each sim crossing, about once a minute +/-.    The LSL throttle is set at 25 HTTP requests in 20 seconds maximum and there is no penalty for exceeding it, you just don't get through so this was a BUG, not a penalty.

 

Tests from non SL sources did not show the problem so that narrowed it down to the SL/Internet interface.  Further experimenting showed it was outgoing HTTP that was being blocked and an error message returned, rather than blocking incoming responses from the data base.  SO FAR changing the URL address by adding a single digit to it has been working with no problems.

---

Thanks for the additional explanation.

I have a large-ish HTTP access system that I've been running tests on for the past few weeks. It uses a distributed approach, but likely has much in common with the HTTPResponse portion of your system, though the throughput (at least on the server end) is likely higher. So far it has been unaffected by this issue, though I will continue to monitor.

The fact that it's responding with a 403 error is quite strange, since the destination server is not generating this, and intermediary hardware should not feed error codes into the loop. A lot of what Qie wrote above makes sense to me, although I can't honestly see why LL would invite that scenario intentionally.

I am curious about:-

• I assume the URI to the files are blocked specifically, and that adding querystring arguments does not force the llHTTPResponse call to complete?
• Are you using method GET or POST? Have you tested both?
• Do you have a 'target' file that returns a pass/fail that Maestro and others can use to test llHTTPResponse against? In the event that this is a bug caused by the server roll, having a file that you can prove to be blocked 100% of the time, would I'm sure be very useful to the JIRA team.

[Phil Deakins]

---

Freya Mokusei wrote:

---

Phil Deakins wrote:

That's an undisputable fact.

---

It is not fact by any stretch of the imagination, your analogy makes no sense. Disciplinary procedures are entirely separate to having script behaviour curtailed in this fashion, especially without warning. See the explanation in my previous post.

Further, yeah, LL are expected to give an explanation to disciplinary proceedings. It's part of the ToS, a part to which they generally hold themselves accountable. And this programmatic system you're describing doesn't exist; you would need a phenominally high volume of llHTTPRequests per object per sim in order to attract any attention - there is no automatic function that would cause scripts stop receiving data via HTTP grid-wide (because that would be crazy). 

---

I'm sorry but you're wrong. I'll try once more...

1. An owner of a system (LL) puts the blocking of something in place. A user's system is blocked because of it. The user redoes the system, using URLs that haven't been blocked. That's circumventing the system owner's system.

2. A system owner ban a user for something. The user does something to circumvent the ban.

Both acts are the same in that they both circumvent the system owner's actions.

Furthermore, the system does not need to inform anyone of any actions. You may expect to be informed but it not a requirement for the system owner.

You are wrong all round.

Incidentally, nobody suggested that blocking the URLs is a "penalty", so that bit of your post was useless.

 

In AnnMarie's latest post, she says that Maestro Linden acknowledges that it is a bug. Fair enough. It doesn't change you being wrong though.

[161488303349]

---

AnnMarie Otoole wrote:

Thanks for all the EXPERT opinions but you don't have a clue what I'm talking about.  .

---

you said linden blocked your http traffic. not everyone's traffic. yours. you gave no explanation for why your traffic has been blocked. you then said that the way you got around the block on your traffic was to change the address

you not appear to know why. like for what reason is your traffic being blocked? for what reason are linden blocking some http and not others? you don't know and just hack your way around it. and by posting here you telling people that this is the fix. doing this is not a fix. is a hack

+

we cant just assume this is an error/bug on lindens part and blithely hack our way around these things when they happen

sometimes we can easy get so caught up in what we doing that we not consider other reasons. like whats happening on the grid at the moment that might require blocking more than before?

is any number of reasons. but can try the obvious one on mainland. goonsquad. that be a really good reason for linden to start blocking some HTTP i  would think

people need be really careful what they do in these situations when get caught up in them. even innocently

best to file a ticket. find out why you being blocked if you are. if you have been added to the chitlist then get yourself removed by following procedure

or can just hack and gamble that your hack is not going to come back and bite you

 

 

[Perrie Juran]

---

Phil Deakins wrote:

---

Freya Mokusei wrote:

---

Phil Deakins wrote:

That's an undisputable fact.

---

It is not fact by any stretch of the imagination, your analogy makes no sense. Disciplinary procedures are entirely separate to having script behaviour curtailed in this fashion, especially without warning. See the explanation in my previous post.

Further, yeah, LL are expected to give an explanation to disciplinary proceedings. It's part of the ToS, a part to which they generally hold themselves accountable. And this programmatic system you're describing doesn't exist; you would need a phenominally high volume of llHTTPRequests per object per sim in order to attract any attention - there is no automatic function that would cause scripts stop receiving data via HTTP grid-wide (because that would be crazy). 

---

I'm sorry but you're wrong. I'll try once more...

1. An owner of a system (LL) puts the blocking of something in place. A user's system is blocked because of it. The user redoes the system, using URLs that haven't been blocked. That's circumventing the system owner's system.

2. A system owner ban a user for something. The user does something to circumvent the ban.

Both acts are the same in that they both circumvent the system owner's actions.

Furthermore, the system does not need to inform anyone of any actions. You may expect to be informed but it not a requirement for the system owner.

You are wrong all round.

Incidentally, nobody suggested that blocking the URLs is a "penalty", so that bit of your post was useless.

 

In AnnMarie's latest post, she says that Maestro Linden acknowledges that it is a bug. Fair enough. It doesn't change you being wrong though.

---

It's the same as a Good Samaritan hacking into a Bank's data base with out permission to help the Bank close a security hole.

Even if the person did no other harm, they still broke the law.

[161488303349]

---

Phil Deakins wrote:

 

In AnnMarie's latest post, she says that Maestro Linden acknowledges that it is a bug

 

---

according to Annemarie previous posts the test she demoed to Maestro was the parcel object entry problem she been experiencing. guess that's changed into a http blocking test now

[AnnMarie Otoole]

UPDATE.

Maestro Linden did further tests and says that it is my data base server that is issuing the error code and blocking the addresses, not Second Life.  In that case I owe SL an apology and kudos to Maestro for his help.

HOWEVER

My server host denies it is blocking addresses and has no facilities to do so.

Bottom line is I go through all my products and change the URL address at both ends.

[161488303349]

---

AnnMarie Otoole wrote:

UPDATE.

Maestro Linden did further tests and says that it is my data base server that is issuing the error code and blocking the addresses, not Second Life.  In that case I owe SL an apology and kudos to Maestro for his help.

HOWEVER

My server host denies it is blocking addresses and has no facilities to do so.

Bottom line is I go through all my products and change the URL address at both ends.

---

thanks for the update

is good that you find out exactly what is the problem affecting you. now you can take proper remedial actions without putting yourself at risk

 

 

 

 

[AnnMarie Otoole]

PENULTIMATE UPDATE.

I got a clue when my commercial web site started giving an Access Denied error message on one function.

With help from the server host it turns out that about 10 of my website URL destinations had the access permissions changed to deny access.

They could not explain why they got changed and no one else has access to the domain control panel except myself.  He suggested that the account had been hacked but why 9 of my Second Life .php programs and one website .php program were locked out while hundreds of others were not attacked is not creditible.  It is more closely related to those URLs with highest activity although none were excessive.

It is comforting to know WHAT happened.  No one knows why.  I'm going to ask the server host for a list of any internal functions that could have set access off but the guy that helped me said he knew of none.

If it happens again I will know where to look.

[Freya Mokusei]

Glad you figured this one out.

As I said earlier, I would've been surprised to hear the Lab was modifying the HTTP stream by altering status codes and blocking connections. Certainly glad this isn't the case, and that the issue was quite easily resolved.

I've seen permissions on files change under some of the following circumstances, though which are likely to apply depends heavily on how you access your server.

 

• Backup restoration
• Incomplete saving of files
• Logged in as limited FTP user, made changes, files inherit limited permissions
• Accidental clicking
• Moving files between folders, where the folders share different permissions

As stated in your post, intrusion is the most likely cause, and definitely one worth ruling out. These things can occur almost by accident too, though.