This is a Call for Consensus (CfC) to publish a new Working Draft of
Programmable HTTP Caching and Serving:
http://dev.w3.org/2006/webapi/DataCache/
As with all of our CfCs, positive response is preferred and
encouraged and silence will be assumed to be assent. The deadline for
comments
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 Jan 1, 2010, at 1:38 PM, Joseph Pecoraro wrote:
Some driveby comments. There were a lot of changes, but these were
just what I caught with a quick scan. I can see you've put a lot
of work into this, Thanks!
General
- 4.1 Introduction
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
- 4.1 Introduction
http://dev.w3.org/2006/webapi/DataCache/#datacache-intro
review policy says (only for unsafe HTTP methods).
Why discriminate? I could see an application wanting to review a GET
request. For example, an application which can be updated by multiple
clients. It may be
There is no way to remove a handler, or all handlers for a particular
namespace, after some have been registered. However, this may be a
valid design decision, because there probably aren't compelling use
cases for removing or replacing handlers. The only time I ran into
this need was running
The normal network timeout logic should apply here.
Ahh, I see. I had not thought about that. Thanks.
In that case, the wording Wait for the ... could be interpreted
as waiting unconditionally. Maybe that could be clarified. I see
many developers getting caught forgetting send() and
On Jan 4, 2010, at 1:26 PM, Joseph Pecoraro wrote:
- 4.1 Introduction
http://dev.w3.org/2006/webapi/DataCache/#datacache-intro
review policy says (only for unsafe HTTP methods).
Why discriminate? I could see an application wanting to review a GET
request. For example, an application which
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
14 matches
Mail list logo
