- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 27 May 2008 14:07:37 +0200
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Web API WG (public)" <public-webapi@w3.org>
On Mon, 26 May 2008 14:49:52 +0200, Julian Reschke <julian.reschke@gmx.de> wrote: > That's understood. But what confuses me is the relation to XHR2 -- it > seems that this WG is splitting time for work on two specs, where just > working on XHR2 would be more useful. It's not exactly splitting time as all the issues raised for 1 affect 2. Maybe it will turn out that 1 is not needed anymore at some point, but for now it seems useful to have. >> I deferred this issue to HTML5 for now by referencing the recently >> introduced definition of "same origin" there. That makes more sense >> because if any changes to that definition are made there it would also >> affect XMLHttpRequest. > > Pointer, please? http://www.whatwg.org/specs/web-apps/current-work/#same-origin >>>>> When they are a string, then taking about character encoding doesn't >>>>> make any sense here. >>>> >>>> Actually, since you need to encode them for the request it does. >>> >>> But that totally depends on the authentication scheme. I think you're >>> confusing layers here. >> >> It does depend on that and that is mentioned. > > Are you referring to: "14. If the user argument was not omitted and is > not null let stored user be user encoded using the encoding specified > in the relevant authentication scheme or UTF-8 if the scheme fails to > specify an encoding."? > > This has two problems: > > - it makes "stored used" an octet sequence, not a string. What is the problem? > - it simply doesn't work in practice, for instance for Basic > Authentication You're not really helping finding the right solution here. This was added for basic authentication if I remember correctly as it does not specify any encoding. >>> How is this relevant for demonstrating the output format for >>> getAllResponseHeaders()? >> >> It's relevant in case people copy the example, which I expect to >> happen. In case they do that and the example would've used synchronous >> code they end up with UI-lockup et cetera, which would be bad. > > Well, we continue to disagree on this point. > > The goal for examples should be to illustrate a specific feature, not to > promote a specific coding practice (at least not when doing the latter > affects the readability). I don't think it affects readability that much. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Tuesday, 27 May 2008 12:07:31 UTC