Talk:LlSetContentType

Too many Questions

we (will) have a pretty new function, but zero information about it... only works for LL's browser / MOAP? (seems like a strange limitation.) only works for the prim owner? (hows that going to work with the internal browser / MOAP, user key/name isn't sent except from llHTTPRequest) I can assume it only works for the script that received the request (since normally other scripts can't respond)

if someone has some better info, it'd be really helpful... if all the above are true, it has zero value, since html from llHTTPRequest can't be displayed as such. if it's just limited to html within SL, it has no use for exporting interface of inworld to the web, but more use for things like huds and distrubuted inworld networks.
-- Void ^{(talk|contribs)} 15:29, 5 August 2011 (PDT)

"for things like huds and distrubuted inworld networks" I think this is exactly the intended use. The exact wording in the release notes was CONTENT_TYPE_HTML "text/html", only valid for embedded browsers on content owned by the person viewing. Falls back to "text/plain" otherwise. The implication is that this is to be used with Prim Media; which should be made clear (and isn't) in the caveat or description. -- Strife ^{(talk|contribs)} 10:20, 6 August 2011 (PDT)

The intended use is to enable HTML based HUDs. I have created an HTML_HUD_Demo.
For the technical nitty gritty:

• The server will check if the user-agent string contains Second Life and revert to text/plain if it doesn't.
• The server will check the incoming IP of the request against the IP of the object owner and revert to text/plain if they don't match.

For HUDs this will work as expected. Non-HUD content may have weird behavior:

• You may set a custom user-agent string to include Second Life in a non-SL browser to view these urls while logged into the region with the content.
• If you run multiple clients from the same IP and logged into the same region you may be able to see HTML rendered content cross-account.
• Poxy and IP anonymizing services are unlikely to work well with this.

In general these are rare and unreliable enough to sufficiently reduce the concern for hosting webpages under the Linden Lab domain name. This feature is *not* meant to enable serving general purpose web pages from LSL scripts.

Kelly Linden 14:25, 26 August 2011 (PDT)

any hope of opening this up to any browser with the secondlife user-agent string? that'd still keep it out of the wider internet and the association clean, while enabling wider use cases within SL.
-- Void ^{(talk|contribs)} 12:46, 30 August 2011 (PDT)

Caveat

I wonder if the Caveats is applicable to the new content types:

• CONTENT_TYPE_XML application/xml
• CONTENT_TYPE_XHTML application/xhtml+xml
• CONTENT_TYPE_ATOM application/atom+xml
• CONTENT_TYPE_JSON application/json
• CONTENT_TYPE_LLSD application/llsd+xml
• CONTENT_TYPE_FORM application/x-www-form-urlencoded
• CONTENT_TYPE_RSS application/rss+xml

Techplex Engineer 10:20, 12 July 2013 (PDT)

this should only apply to the html setting, but I don't want to update the entry without testing first.
-- Void ^{(talk|contribs)} 12:51, 12 July 2013 (PDT)

Multi page HUDS

Why is there no CONTENT_TYPE_CSS defined? Am I missing the point, why it is not required? If you have HUDS with multiple pages would it not make sense to have a common style sheet resource in the HUD script, which can be loaded into the various pages via <link rel="stylesheet" type="text/css" href="/mystyles.css" > ? Or is there a trivial workaround to get this done? (unsigned comment by: Susan Koltai 23:59, 11 February 2016‎)

CSS can be served as text/plain without any problems for the parser, as can javascript. You don't actually have to set a content type for either. This should be true for any text/xyz type except html. Also, please remember to add 4 tildes after your talk page comments to sign them (they are auto replaced with your name-link and time)
-- Void ^{(talk|contribs)} 04:17, 12 February 2016 (PST)