|
|
|
[
Permlink
| « Hide
]
SignpostMarv Martin added a comment - 24/Oct/08 06:41 PM
Since the built-in browser is based on Firefox, this means that developers targeting IE users will have an advantage over anyone wanting to just use the built-in browser, too
 if nothing else, LL's servers should block access from things with IE user agents due to security concerns <.<
If you post me a cap url to play with I'll write you a GM script (if it can be done).
Is it correct that this is an IE6 issue only, and that IE7 properly renders the page as plaintext?
I spoke with one of the http-in engineers, and he says that right now plaintext is forced, and that custom content types may come, but in a later revision of http-in. The issue is also present in IE7, so the problem of developers targeting IE-only demographics are still at an advantage over developers targeting Mac, Linux and non-IE using Windows users.
Something as usuable as llSetHTTPHeader(key request_id,string header); would be nice :-P Yes, having reasonably fast inter-region, inter-object comms is nice, but it'd be nice to be able to write web-based interfaces to vendors (that sits in the vendor itself) that can send a "HTTP/1.1 402 Payment Required" response, directing the user to pay L$ to a kiosk. Not to mention the ability to display rich media entirely in-world via the parcel media- dynamic generation of SVG, custom interfaces to flickr that require no external server etc... llSetHTTPHeader(key request_id, integer header, string value);
E.g. llSetHTTPHeader(lkRequestID, HEADER_CONTENT_TYPE, 'text/html');
Not having real HTTP support is retarded, especially after having made a dog's breakfast of XML-RPC.
Voted. As text/plain by itself, HTTP-In is usable for inter-object comms and AJAX/AHAH type stuff, but it's only useful for direct web-based interaction on Internet Explorer
We have "fixed" this internally so that even internet explorer only gets text now.
Creating human visible/usable/interactable web pages was not design goal at this stage. We are more interested in starting small in scope and limiting potentials for abuse (such as phishing) as possible, while creating a scalable and easy to use alternative to XMLRPC and llEmail. Starting off text-only allows us to open up other content types and behaviors down the road while not miring the existing feature in controversy and feature creep for its initial release. In short this allows us to meet our original design goals in a more timely manner and does not prevent us from going down that path at a later date as warranted. I'm not entirely sure how this can be considered "fixed internally", since the problem lies with IE misbehaving...
Could you elaborate on the fix ? It can be considered fixed internally because it is, as I have said. Even in IE only text will appear and not rendered html.
Viewing the source will show that for IE browsers any html is escaped and the entire body wrapped in html tags. Yes, this can be worked around, and no you don't have to be particularly clever to do it. However at that point you are no longer casually or inadvertently hitting any object's web pages which is our primary concern. Ah, user-agent sniffing to change the output then ?
As stated, for IE you have pre-pended <html> to the http reply. (And possible changed the mime-type with browser sniffing)
Although this appears on the surface to be a resolution, there is no way to break text into lines (linefeed/carriage return) through LSL. \n Sent in the HTTP reply is ignored, and you just end up as a big blob of text. I've also tried sending a CR/LF pair, and that is ignored as well. Short of giving us mime-type control, is there a solution to get a linefeed to display in IE? It works fine in Firefox, Safari, etc. How about prepending <html><pre> or some tag that properly renders plaintext with linefeeds for IE? Such is the disadvantage of using IE, sorry. I do not think this is addressable in the near term. Other browsers (Firefox, Opera, Chrome) should have no problem displaying newlines and you may need to use one of these to debug your script.
Additionally that issue is a new, separate bug that could be linked to this one but is not causing the description of this bug to occur (which is the only reason you would re-open a bug). Thanks!
I'd be interested in some details on what you were doing Day Oh that doesn't work with the html tags in IE.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Resolved
Normal
