On Fri, 05 Feb 2010 23:42:09 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/31/10 7:38 AM, Anne van Kesteren wrote:
Specifically search for inflate and deflate throughout the drafts:
To deflate a DOMString into an byte sequence means to remove from
each code point in the DOMString the
On 1/31/10 7:38 AM, Anne van Kesteren wrote:
Specifically search for inflate and deflate throughout the drafts:
To deflate a DOMString into an byte sequence means to remove from
each code point in the DOMString the higher-order byte and let the
resulting byte (all the lower-order bytes) be
Anne van Kesteren wrote:
On Tue, 05 Jan 2010 13:49:55 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Apart from the obvious worry of switching away from a behavior that
the vast majority of UAs currently implement, with the ensuing
potential for website breakage, sounds fine...
I know...
On Tue, 05 Jan 2010 13:49:55 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Apart from the obvious worry of switching away from a behavior that the
vast majority of UAs currently implement, with the ensuing potential for
website breakage, sounds fine...
I know... Though Opera not having
On Tue, 05 Jan 2010 08:39:26 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking jo...@sicking.cc
wrote:
At the very least, throwing if the upper byte is non-zero seems like
the right thing to do to prevent silent data loss.
That works for me.
Anne van Kesteren wrote:
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking jo...@sicking.cc wrote:
Wouldn't it then be better to throw for any non ASCII characters? That
way we don't restrict ourself for when (if?) IETF defines an encoding
for http headers.
The defined encoding is ISO-8859-1
On 1/5/10 5:03 AM, Anne van Kesteren wrote:
More concretely, this means that combined with the rules coming from
HTTP a SYNTAX_ERR exception would be raised for the value argument if
one of the characters has a code point larger than U+00FF, if the code
point is U+007F, or if the code point is
On Mon, 07 Dec 2009 16:42:31 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
I think XHR needs to elaborate on how non-ASCII characters in request
headers are put on the wire, and how non-ASCII characters in response
headers are transformed back to Javascript characters.
Hmm yeah. I
Anne van Kesteren wrote:
On Mon, 07 Dec 2009 16:42:31 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
I think XHR needs to elaborate on how non-ASCII characters in request
headers are put on the wire, and how non-ASCII characters in response
headers are transformed back to Javascript
On 1/4/10 11:17 AM, Julian Reschke wrote:
For request headers, I would assume that the character encoding is
ISO-8859-1, and if a character can't be encoded using ISO-8859-1,
some kind of error handling occurs (ignore the character/ignore the
header/throw?).
From my limited testing it seems
Boris Zbarsky wrote:
...
Mozilla trunk already does byte _inflation_ when converting from header
bytes into a JavaScript string. I assume you meant to convert
JavaScript strings into header bytes via dropping the high byte of each
16-bit code unit. However that fails the preserve as much
On 1/4/10 3:15 PM, Julian Reschke wrote:
But what's the alternative? Decide the encoding in each case? The
encoding not being predictable seems to be worse than anything else...
Well, one non-destructive alternative is to encode JS strings as bytes
by converting each 16-bit code unit into a
On Mon, 04 Jan 2010 21:57:34 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
If we don't have a requirement to preserve any possible JS string via
this API, then we probably have more flexibility..
I don't think we have that requirement.
I tested Opera a bit further and it seems to simply
On Mon, Jan 4, 2010 at 9:51 PM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 04 Jan 2010 21:57:34 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
If we don't have a requirement to preserve any possible JS string via this
API, then we probably have more flexibility..
I don't think we have
On Tue, 05 Jan 2010 08:29:53 +0100, Jonas Sicking jo...@sicking.cc wrote:
Wouldn't it then be better to throw for any non ASCII characters? That
way we don't restrict ourself for when (if?) IETF defines an encoding
for http headers.
The defined encoding is ISO-8859-1 (unfortunately).
At the
Hi,
I think XHR needs to elaborate on how non-ASCII characters in request
headers are put on the wire, and how non-ASCII characters in response
headers are transformed back to Javascript characters.
For request headers, I would assume that the character encoding is
ISO-8859-1, and if a
16 matches
Mail list logo
