| Key: |
SVC-4582
|
| Type: |
Bug
|
| Status: |
Open
|
| Priority: |
Normal
|
| Assignee: |
Unassigned
|
| Reporter: |
phate shepherd
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
| Last Triaged: |
22/Jul/09 09:11 AM
|
| Linden Lab Issue ID: |
DEV-36328
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escaped equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n along with the less-than greater-than substitutions that it already does.
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n" +
"Also, these Less Than/Greater than symbols <<< >>> should not display escaped in a proper fix.");
}
}
}
Notes: IE text/plain issue - google for IE text/plain
|
|
Description
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escaped equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n along with the less-than greater-than substitutions that it already does.
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n" +
"Also, these Less Than/Greater than symbols <<< >>> should not display escaped in a proper fix.");
}
}
}
Notes: IE text/plain issue - google for IE text/plain |
Show » |
made changes - 17/Jul/09 12:30 PM
| Field |
Original Value |
New Value |
|
Description
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - http://support.microsoft.com/kb/239750
|
made changes - 17/Jul/09 12:32 PM
|
Link
|
|
This issue Relates to SVC-3308
[ SVC-3308
]
|
made changes - 17/Jul/09 12:38 PM
|
Description
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - http://support.microsoft.com/kb/239750
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 17/Jul/09 02:00 PM
|
Description
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Not sure if an <xmp> tag would help or not.
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 17/Jul/09 06:49 PM
|
Description
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Not sure if an <xmp> tag would help or not.
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Not sure if an <xmp> tag would help or not. Another possiblity, since it appears everything sent to IE is going through a pre-processor to convert < and > to escaped characters would be to substitute a <br> for \n ?
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 22/Jul/09 09:11 AM
|
Last Triaged
|
|
22/Jul/09 09:11 AM
|
|
Linden Lab Issue ID
|
|
DEV-36328
|
made changes - 25/Jul/09 11:41 AM
|
Description
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Not sure if an <xmp> tag would help or not. Another possiblity, since it appears everything sent to IE is going through a pre-processor to convert < and > to escaped characters would be to substitute a <br> for \n ?
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Not sure if an <xmp> tag would help or not. Another possiblity, since it appears everything sent to IE is going through a pre-processor to convert < and > to escaped characters would be to substitute a <br> for \n ?
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n Also, these Less Than/Greater than symbols <<< >>> should not be escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 12/Aug/09 09:16 AM
|
Description
|
linefeeds sent with llHTTPResponse to IE are ignored. IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and renders it as HTML. To fix this issue, LL does browser sniffing and if the browser is IE, it prepends "<http>" to the reply sent with llHTTPResponse (and postfixes "</http>").
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, instead of prepending "<html>", it be changed to prepend "<html><pre>"
Not sure if an <xmp> tag would help or not. Another possiblity, since it appears everything sent to IE is going through a pre-processor to convert < and > to escaped characters would be to substitute a <br> for \n ?
Any text after that should be formatted, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n Also, these Less Than/Greater than symbols <<< >>> should not be escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escape equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n Also, these Less Than/Greater than symbols <<< >>> should not be escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 12/Aug/09 09:17 AM
|
Description
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escape equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n Also, these Less Than/Greater than symbols <<< >>> should not be escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escape equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n" +
"Also, these Less Than/Greater than symbols <<< >>> should not display escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 12/Aug/09 09:22 AM
|
Description
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escape equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n" +
"Also, these Less Than/Greater than symbols <<< >>> should not display escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
Linefeeds sent with llHTTPResponse to IE are ignored.
IE is a special case as it doesn't honor mime type "text/plain". Instead, IE assumes the mime type is incorrect and examines the text to determine mime type. If HTML is detected, the plaintext is rendered as HTML. To prevent the page being rendered as HTML, LL does browser sniffing and if the browser is IE, it prepends "<http>" and postfixes "</http>" to the reply sent with llHTTPResponse. This pre-processor also (apparently) replaces the less-than and greater-than symbols with their escaped equivalents to prevent HTML from being rendered in IE.
The problem with this solution is that it is impossible to render a linefeed in the output sent to IE.
What I propose is that if the browser sniffed is IE, modify the pre-processor to substitute a <br> for \n along with the less-than greater-than substitutions that it already does.
Any text after that should be formatted the same as other browsers, and linefeeds honored.
Drop this in a prim cube, and launch the URL chatted. If the URL is opened in anything BUT IE, linefeeds are honored. In IE, it is just one line.
{code:title=server.lsl|borderStyle=solid}
default
{
state_entry()
{
llRequestURL();
}
http_request(key id, string method, string body)
{
if (method == URL_REQUEST_GRANTED)
{
llSay(0,"URL: " + body);
}
else if (method == "GET")
{
llHTTPResponse(id,200,"This \nShould \nBe \nOn \nMultiple \nLines!\n" +
"Also, these Less Than/Greater than symbols <<< >>> should not display escaped in a proper fix.");
}
}
}
{code}
Notes: IE text/plain issue - google for IE text/plain
|
made changes - 03/Nov/09 01:09 PM
|
Link
|
|
This issue is related to by SVC-4990
[ SVC-4990
]
|
|
IE does not render linefeeds sent with llHTTPResponse
