llHTTPRequest to support ephemeral cookie data, more redirects, and better error reporting
tracked
Monty Brandenberg
This starts as a necropost in the scripting forums: https://community.secondlife.com/forums/topic/456090-dont-check-http-in-url-domains/?do=findComment&comment=2692070 OP asserts that until about two weeks ago (call it late January), queries following the unsupported Search API wiki page (https://wiki.secondlife.com/wiki/Search_API) broke. So this may be a breakage issue, an enhancement issue, or an unsupported API matter.
Investigation reveals two things about current LSL HTTP support:
* Cookie data is not honored in any fashion.
* Search web service generates an infinite redirect loop if correct cookie data isn't provided.
This proceeds on the assumption that some attention is needed. One additional item: the command-line versions of 'curl' differ in their support of cookies. The linux 7.64.0 version behaves as our LSL support does dropping all cookie data and demonstrates the infinite redirect loop. The cygwin 7.66.0 version implements some level of ephemeral cooked support by default and gets a proper response after 6-7 redirects.
Some quick hackery with CURLOPT_COOKIEFILE and doubling the redirection limit results in functioning requests to the Search API, as unfriendly as it is to scripting.
Finally, the curl error around this (code 47) isn't reported in the extended error body when this option is selected. It appears that most of the curl-specific errors supply no additional information beyond the final 499 status code. Those could all use some kind of representation where information security isn't a factor.
Log In
Gwyneth Llewelyn
Just to add on the last paragraph: now that there is "extended error support" using JSON, maybe it would be worth considering including
curl
errors there as well? This is true for all sorts of things, of course, not only for dealing with cookies.And what about storing cookies on the KV database? :) I mean, there is no need to invent a 'new' way of storing data, with the eternal confusion of the consequences for how such data is accessed, etc.
Last but not least... you're all aware that cookies are slowly being phased out in favour of things such as localStorage and sessionStorage, right? If you're looking into changing all the above, why not push the code (that includes how the search engine works too, of course) into the 2020s and make it future-proof already? One big advantage of localStorage/sessionStorage is that it's also KV-oriented
and
in JSON. A perfect fit for what LSL already offers!Die, cookies, die! Hehe 😇👼
Maestro Linden
tracked