User talk:Void Singer/Teacup

Minor Optimisation

Great little script! Just curious though about this line: if (~llListFindList( [200, 404], [vIntDta] )){ Is there a particular reason why you went for that in preference of a simple condition? As conditions are always faster: if ((200 == vIntDta) || (404 == vIntDta)){ I assumed it was for readability or ease of editing, but I'm not sure there's really any advantage to searching a static list?
-- Haravikk ^{(talk|contribs)} 06:24, 15 April 2011 (PDT)

I was actually aiming for extensibility.... the 0.1 version actually supported 200, 201, 202, 204, 205, and 404 messages... so that code made a little more sense in that rendition. When I simplified, I just pulled out the currently unused codes to limit invalid link messages triggering the code. I should probably ad some of those back in, but I was considing allowing them to be used internally by file systems.... still kinda up in the air about it. but I'll make sure to comment it for now, and replace it if we reserve it for internal coms.
-- Void ^{(talk|contribs)} 19:53, 15 April 2011 (PDT)

Supporting Extended Return Codes?

Thoughts? should we support any codes that we can reasonably send? some codes we can't, because they require header information (pretty much all of the 3xx codes), or because of the behavior of the cap server (we can't send valid 1xx because the connection gets closed), and some will behave against expectation for the site (205 will reset the page, which effective takes it to the root for compliant browsers, although I've found Firefox and Webkit CLEAR the page). but others are very informative, like sending 204 for post page returns, or 202 for links that trigger inworld actions, etc...

so should we?
-- Void ^{(talk|contribs)} 20:13, 15 April 2011 (PDT)

I know I only waited a few days, but I figured with the new quick 404 handling that I'd run with this one, on at least a limited basis. I've added support for 201 Created, 202 Accepted, 204 No Content, and am using 100 Continue internally to avoid 404's on quiet slow File Services, and misusing 101 Change Protocol (only within the server prim) to tell the server to push the bootsrap page. I hope this makes sense to everyone, and if not I'm open to contradiction as long as alternatives are supplied.
-- Void ^{(talk|contribs)} 09:54, 19 April 2011 (PDT)

Pushing through another added status code today, will now support "403 Forbidden", since I'm now adding IP support to the page requests. I need to do an exhaustive search of the return codes to see what we can legitimately return right now, but as it stands, anyone that finds one that doesn't require header information can simply edit it into the link message code if they find a use for it. I'm also going to transition to using secure URLs so that it makes more sense
-- Void ^{(talk|contribs)} 17:25, 3 May 2011 (PDT)

base46 image encoding transport?

Currently it's possible to embed base64 encoded files into the page IF those files are first channeled through javascript, or in some cases embedded in css files. I'm very open to any method we can use to do this transparently to page loading... for resource types that will accept a "type" attribute AND comply with it against the server's plaintext label.... if there are any.... otherwise they all have to wrapped.

the problem I've encountered so far is that no tags I've found support it, and it will force the page to use some sort of link loading scheme similar to what is used to load html pages now. this has two problems, the first and most major IMO is that we can't use normal tag syntax for things like IMG (because it may attempt to load before we can intercept the request), and secondly, it means that the user has to use custom commands in the page to load them... or direct embedding into the page (which would severely inflate page size)... things I would like very much to avoid.

if anyone has suggestions on a way around this, or thoughts on minimizing or standardizing the methods we do have available, I'd love to hear them.
-- Void ^{(talk|contribs)} 02:05, 17 April 2011 (PDT)

Is it supposed to work on 1.23.5?

All I get is a blank page, and it won't open in external browser at all (FF3.6) Talarus Luan 08:17, 19 April 2011 (PDT)

I'm having the same problem with all of them now... it'll open fine in the internal browser for v2, and you can copy the URL from there and run it in FF3.6, but for some reason the viewer is refusing to pass the url to external browsers, or it's failing some security check in between. I'm going to Jira that today (I thought I had already but I guess not). the odd thing is that I'm sure it was working in v2.6.1 =(

Phoenix(908) has it's own problem with the internal browser, in that the address field is limited to 255bytes. I'm going to try to pinch around it (I have some whitespace I can edit out) but I'll probably have to beg the phoenix devs for a back edit on that one. I'm not sure if that problem was simply imported with snowglobe code but I'll check Cool and see if it has the same problem.... if so then all v1X will probably have the same issue =/
-- Void ^{(talk|contribs)} 09:47, 19 April 2011 (PDT)

Hmm. Well part of the problem was that I was just copying/pasting the scripts from the wiki here into my own objects and it wasn't working. I thought it would give me at least a default page, but the object you sent via group worked. The other problem that appeared is that clicking any of the links on the page causes the viewer to crash. :-/ Talarus Luan 13:11, 19 April 2011 (PDT)

Crash!?! yikes. Perhaps I should disable the touch to llLoadURL handling for now so I'm not borking v1... The pastable scripts from the active page should be working and bug free in v2 now (I copied them directly from the inworld object I was testing on), but I discovered the problem is hairier than I thought at first...

I do a touch load (llLoadURL), the viewer only puts the first 311 characters into the internal browser address line. But if I use the open in browser button that's in the MOAP address bar, the full 1024 characters are available. So that will definitely get a jira today. I'll retest with a v1 viewer and see if I can't reproduce the crash (it's probably a partial truncation problem on the page causing webkit to throw a fit)
-- Void ^{(talk|contribs)} 13:36, 19 April 2011 (PDT)

decided to re-address this with an external script so that buggy behavior isn't included in the core server.... it'll just be a small touch loader script that pulls the current address from the [PRIM_TEXT]... on an experimental basis (so no wiki resource ATM), until I can be reasonably sure it's not going to crash clients. if I find a specific crash it'll go to jira, if anyone else does, the same would be appreciated.
-- Void ^{(talk|contribs)} 17:31, 3 May 2011 (PDT)

Simple Dynamic page

Is it possible to post a simple dynamic(like region stats) page, with some setup description.

I tried to re-use the region stats page, to make a simple page to list some items from a list, but for some reason my script never refreshes the page, even though I can see that it's accesed and creates the html, but the messagelinked() must not be right.

--Frans Charming 16:04, 26 April 2012 (PDT)

when grabbing refreshes for the current page, you must tack on a unique identifier. for example in the region stats refresh I tack the request key onto the link as a search parameter (anything after the url+question-mark)... SL serves the pages with cache flags that specify the page is permanent and this is how you defeat that to serve the same named page with updated content. If you post your current page code (or a simplified version) to either the official forums scripting tips, or better to SLU scripting forum, I (or someone else in the case of official forums) will be glad to make the correction/modification that makes it work. I'll also see about putting up a simplified page example here on the wiki, soonish.
-- Void ^{(talk|contribs)} 07:55, 28 April 2012 (PDT)

418 is a valid HTTP status code...

The original author assumed that, because RFC2324, which defined status code 418 I'm a teapot was a joke, the status code was somehow free to be used.

Well, no, sorry, but that's not how it is!

In fact, IANA, the sole authority for registering all numbers related to the Internet, does reserve status code 418, and it not only refers to RFC2324's usage of the 418 status code, but also that such status code has been implemented in so many different web servers (fact!) that it became ubiquitous — and, as such, could not be used for any other purpose. As such, status code 418 is effectively reserved, meaning: "the IANA assigned this status code for something, and you cannot reuse it freely for anything that wishes to strictly conform to the HTTP standards". In other words: web services, if they wish to conform to the standards, MUST NOT use error code 418 to signal anything relevant (signaling that one is a teapot is, of course, purely optional).

And for the sake of completude — the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) described under RFC2324 was later expanded with proper support for teapots with an extension described under RFC7168, The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA). RFC7168 also uses status code 418, providing compatibility with RFC2324, it just defines new extensions.

Thus, please note that, since the system described as "Teacup" fails to address most of the mandatory specifications of HTCPCP-TEA, it should be explicitly marked as "non-RFC7168-compliant", lest a HTCPCP-TEA client attempts to communicate with it.

Finally, for remotely managing a coffee pot using SNMP, there is also a companion MIB: RFC2325.

Of course the Internet is a very serious matter!

— Gwyneth Llewelyn (talk) 13:37, 12 August 2023 (PDT)

TIL; I also appreciate the additional subtlety of posting at 13:37 -- Nexii Malthus 08:48, 10 September 2023 (PDT)

LOL! That timestamp was purely by chance! 😂 — Gwyneth Llewelyn (talk) 16:03, 6 March 2024 (PST)