llHTTPRequest - Default encoding handling
tracked
zwanni Resident
There is a problem when the encoding is not set correct on a Server
I made tests with a simple php file:
<?php
echo "Hällo Wörld"
?>
A HTTPRequest gives me
> Hällo Wörld
<?php
header("content-type: text/plain; charset=utf-8");
echo "Hällo Wörld";
?>
Here the response is correct
> Hällo Wörld
It seems that when no encoding is set, UTF-8 is not used as default. That's a problem for some translater APIs for example. I don't know if it is possible to set utf-8 as fallback encoding or if a change could produce other issues.
Maybe take a look on it
Log In
zwanni Resident
I did some further tests and the option "Accept-Charset: utf-8" does not solve the problem.
The response content-Type is always:
Content-Type: application/json
...without a charset.
Maybe that was a missing information, because on my first tests the focus was not specific enough. On the translater API we expect a json answer. I found out that json always should be interpreted as utf-8 and there is no need for the server to respond a charset. So LSL seems to guess a charset where it shouldn't do that.
Maestro Linden
marked this post as
tracked
Testing around, I see that some web servers already default to sending a response that includes a
Content-Type: text/html; charset=UTF-8
header, which causes an LSL script to handle the request cleanly.Since your server isn't doing that by default, you'd ideally want to have the headers sent to llHTTPRequest to request that format via the HTTP_ACCEPT option. Unfortunately this option doesn't yet support a "charset" directive, but that should be supported.