Jump to content

Sasun Steinbeck

  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About Sasun Steinbeck

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. OK thank you, the avatar in question as of the 18th (5-ish days after changing his name) it was still not updated (old name in HTTP headers). So we just have to wait until the RC is deployed to the production servers, it looks like. Thanks much for the info.
  2. OK thanks for the info. Can you give me some more details on the bug, I am getting a "You can't view this issue" message when I search on that at jira.secondlife.com. Or is there another way to view that bug?
  3. If I have an avatar that recently changed their name and give them a scripted object that calls llKey2Name(llGetOwner()), it works correctly (it returns their new name). However if the same object sends an HTTP request, llGetHTTPHeader(ID, "x-secondlife-owner-name") returns their OLD name. Is this just a timing issue, are these two methods of getting a legacy name going to be in sync some time soon? I'm assuming that's the case... I don't know exactly when the avatar in question changed their name.
  4. Yeah it's so rare that bombarding my server with umpteen million of the same POSTs for a few months seems like a long shot. I definitely can't even imagine how to reproduce them on demand. I can't see a pattern - in frequency, or the position of truncation, or the originating script name, or region.. but I just realized I've been lax on saving these records for very long so I'll see if there's any kind of date/time pattern, thanks for the suggestion. Don't have enough data to rule that out...
  5. That's a great thought. But in this case, that's not happening. Sometimes the truncation happens right in the middle of a hard-coded parameter name rather than something I'm pulling from the database. And those parameter names don't have any special characters in them. For example in the middle of the string I have "param1=customer_name" or something and it truncates right in the middle of "param1". I've gone over and over my LSL code that's making the HTTP call thinking it must be truncating it here, and that's always a valid possibility, but I really don't think so. I probably get a half million HTTP requests per week and only a few get chopped up like this. And again, I might get two in a row, truncated in different positions on what is almost an identical data string, coming from different scripts in different regions so... I really do not suspect a script bug. The only thing that could affect two http calls from two different scripts like that is not the script itself but something in between the sender script and the receiving website where the data is corrupted.
  6. Sorry I should have noted that the maxlength is far, far beyond the small number of characters where the truncation is happening. by default of course it's 2k and I'm never setting it to less than 2K, ever. I realize this is really a shot in the dark, I'm just so stuck, I really think it's not my code/server. But never say never, I know that all too well. I just wonder if anyone else has ever seen this happening, is it just me? And I should have noted that ALL the requests are coming from my own scripts so I know exactly what is going on, on both ends. The reqests are nothing special... and umpteen zillion of them work just fine with no errors until it glitches once in a blue moon. llHTTPRequest(URL, [HTTP_METHOD, "POST", HTTP_MIMETYPE, "application/x-www-form-urlencoded", HTTP_VERBOSE_THROTTLE, FALSE], postdata); Where URL is my web server where I'm logging the errors. Just for fun here's the full error report for a typical truncation error event. Note that the expected form value for this particular API should look something sorta like: "source=subscribers2&groupname=blahdeblah&mode=subscriber&owner_key=a30b48f3-ecc2-4004-b5a2-fc1f26ef344x" But it's chopping it off right at the beginning of "groupname". So it's a hard-coded parameter name... not any kind of variable... and all the rest of the params are just... gone. Then .07 seconds before this there was a very similar error but the point of truncation was different. The other APi came from a different script in a totally different region, too. So it's not some kind of region glitch. Nor is it a specific LL server glitch since the other POST came from a different server. But it could be some kind of gateway problem or something, I don't know... _____ Error count: 2 minutes since last error: 0.07685149 Base Exception: System.ArgumentNullException System.Web.HttpUnhandledException in Boolean HandleError(System.Exception) Exception of type 'System.Web.HttpUnhandledException' was thrown. HTTP code: 500 System.ArgumentNullException in Void StringToNumber(System.String, System.Globalization.NumberStyles, NumberBuffer ByRef, System.Globalization.NumberFormatInfo, Boolean) Parameter name: String Form: source=subscribers2&g POST From: sim10637.agni.lindenlab.com X-SecondLife-Object-Name: Syndicate Sunday Designer Admin X-SecondLife-Object-Key: d20e5a72-5dcc-ebdc-70bf-3bbdd003a3b1 X-SecondLife-Owner-Name: Ylva Somebody X-SecondLife-Owner-Key: x30b48f3-ecc2-4004-b5a2-fc1f26ef3441 X-Secondlife-Shard: Production http://slurl.com/secondlife/Somewhere/167/22/2996
  7. I've been plagued by a very occasional problem for a very long time now (years?) where a few HTTP POST requests from in-world to my web server get truncated. So for example I make a normal HTTPrequest() POST request from a script to my web server with data like param1=bob&param2=fred and it arrives at the server truncated, for example I might get "param1=b" or "param1=bob&pa". These cause an error on the server because required parameters are missing, so they all get logged. These result in an error 499 returning to the script inworld. Since I typically have lots of http requests coming in, I'll get these in very small batches, maybe 2-3 over the course of just a few milliseconds, sometimes it might be the same API call and the location of the truncation in the post data appears to be pretty random. I might get two identical API calls a few ms apart that are truncated, but at different positions in the data. It isn't related to a particular API, it happens to all of them, but there are a few that get called far, far more than others so naturally the distribution is weighted toward those heavily called APIs. These are extremely occasional, maybe I'll get a batch of 1-3 all within a few milliseconds, a week apart, or two weeks or who knows. Considering I'm getting maybe 1 HTTP request per second (some GETs, mostly POSTs) from in world scripts, pretty much 24x7, over the course of a week that's a lot of perfectly fine requests until another little batch of truncated requests comes in. Has anyone else seen anything like this that's logging bad HTTP calls at the web server level? I just don't see any pattern to these mystery truncations. It's not a huge issue but it's been nagging me for ages and I just wonder what is going on. I'm convinced it's some kind of LL server glitch and they are being sent truncated. I've never seen this happen to any HTTP requests other than from an inworld LSL script. I really don't think it's an issue with my web server (Azure web app), but hey you never know. But I heavily suspect they are being sent truncated.
  8. OK I think I have a good handle on how this affects me and my various systems and scripts. But I have one super vital question: will search in the viewer work with retired (historical) names? Will it find the correct avatar, even with their old names? Same question for https://search.secondlife.com/ but that is much less important to me.
  9. Yeah thanks! BTW for those interested I found this very helpful to understand the confusing name situation on various SL properties: http://wiki.secondlife.com/wiki/Category:LSL_Avatar/Name
  10. This would be critical functionality to impement. They HAVE to do this. Up until this minute legacy names were guaranteed to never change and always be unique. So let's say you have a list of subscribers to a list. Instead of exporting a list of UUIDs, you could export a list of legacy (or account!) names and be safe in the assumption that those were always useable, meaning, you could re-import them and in some way or another convert them to unique UUIDs. Now if that assumption is broken that is really going to screw up a lot of people that happen to have lists of avatars for whatever reason (sales logs, committee memebers, whatever) that are now broken. If you re-import them and half of them are completely unknown because the avatar changed their name... what a mess. Big problem. The only reasonable thing to do and not break a zillion tools and external lists that make those (previously perfectly safe) assumptions that legacy names will always be tied 1-to-1 to a UUID is to make ALL names, historical + current, be searchable/convertable to a unique UUID. Anything less will really screw over a lot of people.
  11. When you say "always use UUID values", yeah that's true when storing a list of avatars in some way. A database of legacy or account names only is indeed useless which I think is what you are getting at. For most APIs you need UUIDs so that's nothing new. For messages and whatnot to end-users, obvious I need to use something friendlier than a UUID, display names are useless as they can change on a whim, so I need to understand the details behind legacy names (and accout names, if they are changing too?) As a scripter I'll definitely need more specifics than general guidelines. Exactly how will the APIs change? Exactly how will llKey2Name() change? Under what conditions does it return a different name for the same UUID? What about llGetObjectDetails? What about llGetUsername? Will user names remain the same and never change or will they follow legacy name changes? Will legacy names still be called legacy names or will there be new terminology? llRequestAgentData? What about llDetectedName()? What about names passed into listen events? llSensor()? AGENT_BY_LEGACY_NAME? What about the q parameter for search.secondlife.com/web/search/? What about the q parameter for search.secondlife.com/client_search.php?s=people ? How will the results returned by those URLs change? What about the names shown for an avatar's web profile i.e. http://world.secondlife.com/resident/c3cf4c84-c31b-47ac-855c-3858375e0360 ? Do I need to store multiple names for every avatar UUID now? Will there be an API to get all (current + historical) legacy names from an avatar UUID? Or will all APIs like llKey2Name and llRequestAgentData only return one legacy name, the latest one? Can I look up a UUID from an old legacy name after it has been replaced? As you can see there are a lot of details that need to be known for scripters to fully understand what to do. I'm looking forward to the gory details.
  12. Just wondering if any detailed information exists yet on LSL API changes related to the upcoming avatar name changes. If not, where and when can we expect some details? I'm really hoping there are no breaking changes, but I need to know what is going to happen specifically to the APIs and any changed assumptions about avatar names before any changes roll out so I can get any necessary updates to my products out there.
  13. Yep that sounds like the best bet, thanks, just wanted to make sure I wasn't missing something about getting that retry header
  14. @Oz Linden one followup, how can I get the Retry-After header in the 503 response? The request is coming from an in-world script... llGetHttpHeader() in an http_response event doesn't work. I can't seem to get any of the usual expected response headers that way.
  15. I love how the second assumption in that bug report is that it's an evil conspiracy, lol.
  • Create New...