Oz Linden

Lindens
  • Content count

    150
  • Joined

  • Last visited

Community Reputation

94 Excellent

4 Followers

About Oz Linden

  • Rank
    Advanced Member
  1. llHTTPRequest changes

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

    Solution to what?
  3. llHTTPRequest changes

    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.
  4. llHTTPRequest changes

    Please file a Jira on this one. Be sure to include where it is happening and an object that demonstrates the problem. We certainly didn't do anything like that on purpose, so it will take some work to figure it out but we need more specific information to start.
  5. llHTTPRequest changes

    I added the note above to the original post. Sorry that caused problems for a few services; I made the change because when we added the ability to append your own User-Agent values, we included checks on valid syntax and since our own value would not have passed that check, I thought it only fair to correct it. Perhaps that wasn't the best tradeoff, but now that it's done we won't change it again.
  6. llHTTPRequest changes

    That looks right ... what is the value of nPlayingURL ? Do you get an error message?
  7. llHTTPRequest changes

    I think you underestimate the ability of SL Residents to adapt. For some history of why we made this change, see my posts in https://community.secondlife.com/forums/topic/406941-dj-board-display-not-working-properly/ I regret that it wasn't reasonable to make an automatic adjustment in the simulator to correct this, but sometimes that's the way it works out. We try to keep disruptions like this to a minimum, and I'm making a special effort on this one to reach out to the authors of scripts that are affected. Frankly my biggest regret is that the URL hack was not noticed long ago and a better solution (like the current one) provided then (well before my time, but that's an imperfect excuse) - it should never have worked and it's surprising to me that it ever did. Software surprises you that way sometimes. We have a couple of other improvements to llHTTPRequest in the pipeline (ones that won't break anything); watch this thread for announcements when they're available for testing.
  8. llHTTPRequest changes

    In the latest main channel simulator version (2017-07-11T22:13:46.327548), we deployed some updates that changed the llHttpRequest call. These were made necessary by updates to some of the underlying HTTP libraries we use, and are intended to make HTTP use from LSL easier to debug and more robust, but in a few cases they have broken some existing scripts. This note is intended to summarize the changes and provide guidance on how to update your scripts. URLs The most important change, and the one that seems to be responsible for most of the problems that have been reported, is in the handling of the URL parameter. In previous versions, the URL was not checked, and some scripts had done things that shouldn't have worked (and now they don't): Control characters in the URL. Specifically, this has usually been newline characters. There were widely used hacks that inserted newlines in order to get around restrictions on the use of some headers, and those hacks also truncated other important headers that the simulator inserts in all requests. This will now produce a run time error without sending the request. The fix is to remove the newlines and any additional headers they were inserting; if it was the User-Agent header, there is a new parameter you can use to provide a value for that header. Spaces in the URL. Space characters are not allowed in URLs, but because many scripts insert them, we have put in special handling to convert them to a %20 in most cases. If your script is passing values returned from other LSL calls that may return spaces, you should do the replacement before putting them into the URL, like: string URL = "http://example.com/path?region=" + llEscapeURL(llGetRegionName()) depending on how your server works, you may need to substitute a plus sign ('+') for the spaces in parameter values rather than the '%20'. Header Value Changes We added a new HTTP_USER_AGENT parameter that lets you append to the User-Agent header value; in some cases, servers look for key words in this header. We made requests shorter by sending one long Accept header with all the allowed MIME types rather than many headers with one each. This made requests shorter and more compatible with more servers. As far as we know it has not caused any problems. The default User-Agent header server token value was changed from 'Second Life LSL' to 'Second-Life-LSL'; this appears to have caused problems for some servers that were checking for it. Problems If you are having problems with these changes, you may reply on this thread or file a JIRA and we'll make an effort to help you. Please include the part of the script that is making the call to llHTTPRequest and the values that are being passed to it, and describe any errors you are getting on the Debug chat channel or from your web server.
  9. Massive ping times on login

    The 'ping' value on the status bar cannot be compared to the times for a traceroute or ping command; it's an entirely different mechanism with quite different performance. The viewer displays the times for application messages that are processed by the simulator; those other commands display times for network packets that are handled at a much lower level and so are normally significantly faster. The login servers are separate from the simulators. To measure connectivity to login, the name to test is login.agni.lindenlab.com (which is really any one of many redundant servers). With as little as there is in your post to go on, it's impossible to guess what your problem might be but we monitor the responsiveness of login servers very very closely and they are fine, so chances are that the problem is either something in your system or in the network between you and the server.
  10. DJ Board Display Not Working Properly

    This change is rolling to the main channel now, and will roll to any RC channels it isn't already on in tomorrows roll. Apologies for the delays and difficulties.
  11. DJ Board Display Not Working Properly

    Due to an unrelated issue, the scheduled roll of this version to the rest of the grid will not happen this week.
  12. Need Help with putting my club in search

    To be clear, that's L$30. Note also that enabling Search also gives you a Place Page - a Linden-hosted web page linked to your land that you can customize.
  13. DJ Board Display Not Working Properly

    This script, which requests a json response and then uses the llJsonGetValue to parse it, worked with that server: key kSentRequest; string host="stardust.wavestreamer.com:8062"; string path="/stats?sid=1&json=1"; string stream_status; default { state_entry() { string URL = "http://" + host + path; llOwnerSay("URL:"+URL); kSentRequest = llHTTPRequest(URL,[],""); } http_response (key kRecRequest, integer intStatus, list lstMeta, string strBody) { string title = llJsonGetValue(strBody, ["songtitle"] ); llOwnerSay(title); } on_rez(integer start_param) { llResetScript(); } } In this case, adding a User Agent was not needed, but apparently some Shoutcast servers can be configured to either require or prohibit certain user agents.
  14. DJ Board Display Not Working Properly

    I tried that stardust wavestreamer manually with a few different variations; all returned 403. That status normally means "I know who you are, and you're not allowed to see that". Maybe you could ask the server owner why not?
  15. DJ Board Display Not Working Properly

    Spaces are not valid in a User Agent token. Try [HTTP_USER_AGENT,"XML-Getter (Mozilla Compatible)"] - even better would be , [HTTP_USER_AGENT,"XML-Getter/1.0 (Mozilla Compatible)"]