On Tue, Nov 12, 2013 at 5:20 PM, "Martin J. Dürst"
<duerst at it.aoyama.ac.jp> wrote:
> If XMLHttpRequest has reasons to continue allowing it, I'd suggest that:
> 1) It strongly discurages it, and
> 2) It defines processing as something roughly like
>    a) If the first few bytes look like a BOM, ignore them
>    b) Process the rest according to rfc4627bis or ECMA-404 (whichever works
> better if they are not in full alignment).
>
> That will make sure that variation is confined as locally as possible.

So that is roughly how it is defined. Using the web's "utf-8 text
resource decode" method that removes a BOM and then passing the rest
to something equivalent to JSON.parse(). However, if we are defining a
new text transport format I think it would make sense to allow a
leading BOM similar to how text/css, text/html, etc. allow for that.


-- 
http://annevankesteren.nl/

On Tue, Nov 12, 2013 at 5:20 PM, "Martin J. Dürst" <duerst at it.aoyama.ac.jp> wrote:
> If XMLHttpRequest has reasons to continue allowing it, I'd suggest that:
> 1. It strongly discurages it, and
> 2. It defines processing as something roughly like
>    1. If the first few bytes look like a BOM, ignore them
>    2. Process the rest according to rfc4627bis or ECMA-404 (whichever works better if they are not in full alignment).
>
> That will make sure that variation is confined as locally as possible.

So that is roughly how it is defined. Using the web's "utf-8 text
resource decode" method that removes a BOM and then passing the rest
to something equivalent to JSON.parse(). However, if we are defining a
new text transport format I think it would make sense to allow a
leading BOM similar to how text/css, text/html, etc. allow for that.