Jump to content

Monty Linden

Lindens
  • Posts

    522
  • Joined

Posts posted by Monty Linden

  1. A 'ping' won't tell you much, particularly that one.  'lindenlab.com' is the corporate website and the fronting services likely block ICMP.  Login occurs on 'login.agni.lindenlab.com' and that is responding to ICMP pings but that's not a promise.  The 'Access Denied' bit *is* useful and you may be able to take that 'Reference #' to support for help.  And it may clear on its own after some hours.

    • Like 2
    • Thanks 1
  2. The 'feedback' issues (Canny) represent new development including a new external service.  That doesn't happen in days (when I said 'slow,' I really meant slow).  That's why you need to follow through with a support ticket and maybe a bug report in feedback.  These have faster return times (but not always with the response residents want).

    • Thanks 1
  3. I'd expect the viewer to composite the information sources to produce lists and visual feedback (caveat:  never dug into this system before).  New inventoried LMs certainly show up for me.  But I can also imagine that stale inventory cache would leave things around to be found by the map code.  The LM list in the world map also appears to index by name and so non-identical LMs with the same name might be considered identical to the map.  This looks like a grand opportunity for filing some Canny bugs!

    • Like 1
    • Thanks 3
  4. There is an order to it.  The idea being to slough off suitable victim objects when limits are encountered.  But the specification is complicated and subject to change without notice.  If you experience something that seems at odds with sensible victimhood, just file a bug because it needs attention from time to time (and I believe has received some recently).  Such bug reports should have as much detail as possible (region, parcel, location, time, date in the Mayan calendar, etc.).  This thing is a function of 47 or more variables.

    • Like 2
    • Thanks 3
  5. 5 hours ago, Ardy Lay said:

    For a "living document", that wiki has a lot of necrotic tissue.

    Bwahaha, we used a lot of phlogiston back in those days.  Those appliances are long gone.  Along with the Isilons and more.  I'm surprised the URL patterns still worked or that anything on that page still applies.

    I'm trying to bracket when the externally-visible behavior changed.  I'm not web but I'm not seeing a cause...

    • Thanks 1
  6. 1 hour ago, Love Zhaoying said:

    Again, sorry if I was not clear:  if there was an (easy or obvious) solution, Monty would have provided it!

    Perhaps another user will see your thread and chime in with a helpful response that includes how they got to "search" from within LSL code using llHTTPRequest().

    Well, it was late and so I didn't (and still don't) have all the answers.  There will probably be some issues filed on this (and I'll mention them here).  And I'm going to run down some other answers.

    The Search API page is notable for having last been edited in 2011.  (Almost typed 1911.)

    The curl command (now edited) isn't a solution for you, @VirtualKitten.  But it is a tool that allows you to see what is occurring.  The exciting thing is that it also exposes some bugs in curl (which we use internally).  Curl 7.64.0 and 7.66.0 handle cookies slightly differently and we may be  triggering something.

    @VirtualKitten, when did this stop working for you?

    • Like 1
    • Thanks 1
  7. Well, I can answer what the root error cause is (though several are involved in this case):

    URLRequest Error: 47, Number of redirects hit maximum amount, http://search.secondlife.com/?query_term=Galadriel%27s&search_type=standard&collection_chosen=events&maturity=gma

    Too many redirects and that information isn't passed back in any useful way.

    • Like 1
    • Thanks 2
  8. On 2/14/2024 at 7:49 AM, VirtualKitten said:

    I think the search.secondlife.com is either a NAME Index for a URL or a similar DNS service  that does the same this is why it returns no files  . Can you provide the proper search URL please and not a Named IDX or similar service? As I think this is most likely what i transpiring.

    DNS chains are silently followed and wouldn't cause this problem (ignoring TLS cert validation for the moment).  If you run your search query through a 'curl' command such as:

    curl --http1.1 -v -L -o /dev/null 'https://search.secondlife.com?query_term=Galadriel%27s&search_type=standard&collection_chosen=events&maturity=gma' 

    you will see the sequence of visits that are made as the request gathers state information into cookies.  There are a number of possible reasons for llHttpRequest failing on this:

    • cookie management during the request
    • redirect count (3xx codes)
    • other limits (header length, response body length)
    • Like 1
    • Thanks 1
  9. I think I agree that this should be better available.  The support ticket is one way to try to kick things.  You might also want to go to https://feedback.secondlife.com/ and file a bug or feature request on this.

    I noticed the redirection chain is going through an auth endpoint and is doing a good amount of cookie churn to pass context along.  There may be a way to start in the middle of the chain and get a search result back easily.

    • Thanks 1
  10. Necropost!  Doubly so as oz is no longer here.  A quick check with 'curl' shows that that URL needs to go through about seven 3XX redirects to finally produce output and the final response is about 24KB.  I suspect http-out limits are generating a 499 error and extended error status would provide more information.  (I haven't checked this - just throwing it back out there.)

    • Thanks 1
  11. 9 hours ago, animats said:

    Check me on this. I may have misread something.

    Oh, it's almost certainly true.  It's what you get with evolution through a series of errors rather than design.  The simulator didn't spec or implement the right thing.  The viewer made an adaptation keeping old caps around.  Simulator then had to follow the viewer keeping old caps alive per viewer spec so implements weak persistence and caching.    That cache doesn't always work as expected with undocumented lifetimes, etc., and the viewer adapts freezing the evolved spec at a new behavior.  Repeat.

    The texture and mesh caps are 'local' resources that will supply grid-wide data, even before CDN, so likely showed up here first.  Inventory and other APIs have similar looks-local-acts-global scope.  But some really are local and you need those caps.  Or you end up using another simulator as proxy.

    I really do tip my cap to the OS people for trying to chase this moving target with very little help from us...

    • Like 3
    • Thanks 1
×
×
  • Create New...