| 04:00 | <Redface> | im at seoul digital forum. Tim Buners Lee showed up yesterday and today is for Jessica Alba |
| 09:24 | <hallvors> | darobin: busy? |
| 09:28 | <darobin> | hallvors: sort of, why? |
| 09:29 | <hallvors> | I was told to ask you for help fixing some settings on w3c-test.org |
| 09:29 | <hallvors> | (unfortunately, I don't know what exactly needs changing) |
| 09:29 | <hallvors> | But this test fails because the server doesn't allow PHP to send custom HTTP status text: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/status-basic.htm |
| 09:31 | <hallvors> | (If somebody else is less busy and could fix it, just tell me who to talk to) |
| 09:31 | <hallvors> | GET http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/resources/status.php?code=502&text=YO&content=&type= should say "502 YO", not "502 Bad Gateway" |
| 09:34 | <annevk> | heh, I wrote that test :-) |
| 09:35 | <hallvors> | annevk: I know :) |
| 09:35 | <annevk> | happy to break both browsers and servers |
| 09:35 | <hallvors> | you don't happen to know an Apache pref that needs changing? |
| 09:37 | <Ms2ger> | I say we have darobin set up that python server we've been talking about |
| 09:37 | <darobin> | hallvors: ah yes, that's a known bug |
| 09:37 | <darobin> | Ms2ger: that won't happen today, but it would indeed be good |
| 09:37 | <Ms2ger> | Tomorrow? :) |
| 09:38 | <darobin> | hallvors: I need to divide and conquer the terrible mess that the Apache config is there to figure out why it won't allow that |
| 09:38 | <darobin> | Ms2ger: it will be the tomorrow of some day :) |
| 09:38 | <Ms2ger> | Heh |
| 09:38 | <Ms2ger> | Hmm, is http://www.w3.org/Style/css2-updates/css2/ actually public? |
| 09:39 | <annevk> | darobin: maybe it's something from PHP? |
| 09:39 | <darobin> | annevk: that's certainly possible too |
| 09:40 | <darobin> | that's one of the many things I love about PHP, it has so many configuration options and so many ways of setting them that you're always certain that it'll just work the same across machines |
| 09:40 | hallvors | 's irony detector just got triggered |
| 09:41 | <hallvors> | annevk: did you see my attachment in the XHR auth bug? |
| 09:41 | <SteveF> | darobin: i want to move using aria doc to github whats the procedure? |
| 09:41 | <darobin> | SteveF: you want it under the w3c account? |
| 09:41 | <SteveF> | yes as its a html wg deliverable |
| 09:42 | <darobin> | SteveF: ok, what shortname do you want? |
| 09:42 | <annevk> | darobin: how is PHP run? |
| 09:42 | <darobin> | annevk: I think through mod_php (IIRC) |
| 09:42 | <SteveF> | darobin: aria-in-html |
| 09:43 | <SimonSapin> | Ms2ger: why not? It’s an ED |
| 09:44 | <SimonSapin> | I’m not sure why it’s not under http://dev.w3.org/csswg/ |
| 09:44 | <Ms2ger> | SimonSapin, do you know how hard it is to get Bert to make an ED public? |
| 09:44 | <SimonSapin> | not really |
| 09:45 | <SimonSapin> | but I think it’s good that it’s public |
| 09:45 | <annevk> | hallvors: no, pointer? |
| 09:45 | <Ms2ger> | It is good indeed |
| 09:45 | <Ms2ger> | Would be interesting to see when the wg first resolved to make it public, and when it actually became public |
| 09:46 | <hallvors> | question: when I push something to GitHub, how long does it take until the corresponding /submissions/ folder for the pull request is updated on w3c-test.org? |
| 09:46 | <jgraham> | "it depends" |
| 09:46 | <annevk> | Ms2ger: is: http://www.w3.org/Style/css2-updates/css2/,access |
| 09:46 | <SimonSapin> | we resolved in February to have one, not sure about publicity |
| 09:46 | <jgraham> | It should be quick (it is push based, not intermittent polling) |
| 09:47 | <jgraham> | But sometimes the github queue gets backed up and you have to wait |
| 09:47 | <hallvors> | annevk: bug 15418 , attachment: https://www.w3.org/Bugs/Public/attachment.cgi?id=1353 |
| 09:47 | <hallvors> | jgraham: thanks |
| 09:47 | <hallvors> | ah, updated now :-) |
| 09:47 | <annevk> | hallvors: guess I don't get email for attachments |
| 09:48 | <annevk> | Ms2ger: what's the Python server you've been talking about? |
| 09:48 | <SimonSapin> | Ms2ger: "RESOLVED: Develop text for CSS2.1 PER as open editor's draft (while continuing to maintain errata). Publish PER when we're done & have updated implementation report" http://lists.w3.org/Archives/Public/www-style/2013Feb/0382.html |
| 09:48 | <SimonSapin> | it says "open" |
| 09:48 | <Ms2ger> | annevk, a magical solution for all our problems |
| 09:49 | <Ms2ger> | annevk, in python |
| 09:49 | <annevk> | Ms2ger: ah, sounds like what I've been arguing for for a while, but never created (other than simpleserver which I stole from Aleto) |
| 09:49 | <Ms2ger> | annevk, but it needs someone to do work, so, yeah :) |
| 09:50 | <SimonSapin> | what kind of python server? |
| 09:50 | <Ms2ger> | For testing |
| 09:50 | <jgraham> | A perfect one |
| 09:51 | <Ms2ger> | That I can run in Mozilla automation |
| 09:51 | <annevk> | hallvors: that diagram doesn't work |
| 09:51 | <hallvors> | well, what's the problem? |
| 09:51 | <annevk> | hallvors: also, user agents do challenge even if user/pass are provided in URL |
| 09:51 | <annevk> | hallvors: and user/pass in open() are just copied to the URL |
| 09:52 | <hallvors> | Opera doesn't, I think |
| 09:52 | <annevk> | hallvors: so those are equivalent |
| 09:52 | <hallvors> | (and it seems like bad UI :-p) |
| 09:52 | <annevk> | Rebel Opera or Clone Opera? |
| 09:52 | <hallvors> | Rebel |
| 09:52 | <hallvors> | of course :-p |
| 09:52 | <annevk> | hehe |
| 09:52 | <annevk> | well wait |
| 09:52 | <annevk> | challenge does not mean prompt |
| 09:53 | <Ms2ger> | No, it means challenge |
| 09:53 | <hallvors> | hm.. not following you then |
| 09:53 | <hallvors> | by "challenge", do you mean "send request without authorize first"? |
| 09:55 | <hallvors> | in the diagram, user/pass in open() are handled just like in URL.. |
| 09:55 | <hallvors> | so I'm still not sure what's not working for you |
| 09:55 | <annevk> | hallvors: send request, if get a 401, redo request with Authorization header |
| 09:56 | <annevk> | hallvors: http://wiki.whatwg.org/wiki/HTTP_Authentication has my notes |
| 09:56 | <annevk> | hallvors: http://fetch.spec.whatwg.org/#concept-basic-fetch has it in spec language |
| 09:56 | <annevk> | my idea is to obsolete most of XHR's HTTP infrastructure with that spec |
| 09:58 | <hallvors> | I just need enough details somewhere to make sure XHR tests have usable pass conditions :-p |
| 09:58 | <annevk> | hallvors: okay, so one problem with your diagram is that for cross-origin and credentials in the URL, you don't want to transmit an Authorization header |
| 09:59 | <annevk> | hallvors: in fact, you just want to return the 401 |
| 09:59 | <hallvors> | (btw I want to split up your send-authentication.htm into multiple tests. It's pretty hard to get an overview of what it tests, and some browsers throw a ton of auth prompts at you) |
| 09:59 | <annevk> | hallvors: please do |
| 09:59 | <annevk> | hallvors: that test was more a proof of concept than an actual test :/ |
| 09:59 | <annevk> | I should probably not have checked it in without understanding it as much as I do now |
| 10:00 | <hallvors> | - CORS and credentials in URL should send Authorization header *if* target server allows it and withCredentials is true, no? |
| 10:00 | <annevk> | ooh, what I'm not handling yet is the conflict of Authorization via setRequestHeader() and credentials via URL I just realized... |
| 10:01 | <hallvors> | (and if target server sends 401 or there is a 401 response cached) |
| 10:01 | <hallvors> | annevk: in XHR spec, right? |
| 10:01 | <hallvors> | that's too high level for Fetch, I presume. |
| 10:01 | <annevk> | no Fetch is the perfect place I think |
| 10:02 | <annevk> | it'll get the headers and the URL so it can make a sensible decision |
| 10:02 | <annevk> | whatever sensible is :) |
| 10:02 | <hallvors> | IMO header should "win" |
| 10:03 | <hallvors> | because from JS authors PoV, it's set later |
| 10:03 | <annevk> | well I guess if you set a header you don't wait for challenge |
| 10:03 | <annevk> | so I guess in a way that's already handled |
| 10:04 | <annevk> | back to your question... |
| 10:06 | <annevk> | hallvors: so yeah, I think we could allow that. My main question with CORS and URL credentials is whether it's a lot of additional complexity and whether that'll actually be used or whether we're just wasting implementer resources... |
| 10:08 | <hallvors> | https://www.w3.org/Bugs/Public/attachment.cgi?id=1355 |
| 10:08 | <hallvors> | changed handling of cached credentials (per your wiki notes) |
| 10:09 | <hallvors> | IMO it doesn't seem to add a lot of complexity.. but we could of course request a small implementor review for this. |
| 10:18 | <annevk> | hallvors: you're missing the entry point of no supplied credentials and getting a 401 back |
| 10:18 | <annevk> | hallvors: and getting a 401 back with a malformed WWW-Authenticate header or some such |
| 10:19 | <hallvors> | shouldn't that just be passed on to the JS? |
| 10:19 | <annevk> | no we prompt |
| 10:21 | <hallvors> | I think we should avoid that if possible.. |
| 10:21 | <hallvors> | (and by "if possible" I mean "if it has no compat impact"..) |
| 10:21 | <annevk> | pretty sure we have to prompt |
| 10:21 | <annevk> | I think we also prompt if the credentials turn out to be incorrect |
| 10:22 | <darobin> | SteveF: you should be good to go with https://github.com/w3c/aria-in-html |
| 10:23 | <annevk> | hallvors: also, I think if you set the Authorization header, for cross-origin, you don't need withCredentials to be true and the server to say both Allow-Credentials and opting in for that header... |
| 10:26 | <hallvors> | Hm.. need to think about that. It should be an easier concept (and implementation) to treat all credentials equally, but in the scheme right now setting an Authorization header and not setting .withCredentials means a cross-domain request is just terminated. |
| 10:31 | <annevk> | setting an Authorization header is just very different from using open() -> URL credentials |
| 10:34 | <hallvors> | Agree, to some extent. But then it would be easier to not apply .withCredentials to HTTP auth at all |
| 10:34 | <SteveF> | darobin: thanks |
| 10:34 | <hallvors> | so cross-origin HTTP auth would depend only on whether target server says it accepts Authorization |
| 10:35 | <hallvors> | (effectively .withCredentials would then be .withCookies I guess) |
| 10:36 | <hallvors> | (it's already a bit confusing to have both anonymous flag and .withCredentials. It's not really obvious why both are needed.) |
| 10:38 | <hallvors> | annevk: http://www.lucidchart.com/invitations/accept/518393da-9438-47e2-9d30-08f60a000d50 |
| 10:39 | <annevk> | anonymous flag does more |
| 10:40 | <SteveF> | darobin: what should i be calling the spec doc? |
| 10:40 | <hallvors> | hides Origin: |
| 10:40 | <annevk> | we also never prompt for cross-origin |
| 10:40 | <annevk> | at the moment |
| 10:40 | <SteveF> | darobin: Overview,html? |
| 10:41 | <annevk> | that's why URL credentials are not handled for CORS |
| 10:41 | <darobin> | SteveF: nah, use index.html |
| 10:41 | <SteveF> | ok thanks |
| 10:41 | <darobin> | Overview.html is an antique W3C convention that dates back to when the world hadn't settled on index.html |
| 10:41 | <annevk> | anonymous flag sort of forces all requests to be CORS requests, whereas withCredentials only takes effect for those requests that are actually cross-origin |
| 10:42 | <annevk> | (fetch makes this somewhat clearer I think) |
| 10:42 | <SteveF> | darobin: :-) |
| 10:42 | <hallvors> | why is that distinction required? |
| 10:42 | <annevk> | hallvors: say withCredentials is false |
| 10:42 | <SteveF> | darobin: all i need to do now is get the editors draft url redirected right? |
| 10:42 | <hallvors> | i.e. could we say .withCredentials defaults to true for local, false for CORS but can be set to the other value? |
| 10:43 | <annevk> | hallvors: I request same-origin /test which redirects to http://cross-origin.example/test |
| 10:43 | <annevk> | hallvors: the first request will have credentials, the second won't |
| 10:43 | <darobin> | SteveF: you can do that with an .htaccess |
| 10:43 | <hallvors> | (and allow setRequestHeader('Origin', 'about:blank') ) |
| 10:43 | <annevk> | hallvors: however, with the anonymous flag set, neither would |
| 10:43 | <annevk> | hallvors: that's not a valid value for Origin |
| 10:44 | <SteveF> | darobin: me dumb, ok will check it out its current url is https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html |
| 10:44 | <darobin> | SteveF: I wouldn't worry too much about that |
| 10:44 | <SteveF> | OK |
| 10:45 | <darobin> | SteveF: just including a link to the new in a warning box on the old is fine too — in fact it may be better as it keeps history and all |
| 10:45 | <SteveF> | darobin: and get other editors access |
| 10:45 | <SteveF> | darobin: is that something I can do myself? |
| 10:45 | <hallvors> | Oh, it's "referrer source" wich isn't exactly Origin.. |
| 10:45 | <hallvors> | If the anonymous flag is set, the URL "about:blank", and the referrer source otherwise. |
| 10:47 | hallvors | keeps stumbling across the XHR-Fetch line |
| 10:47 | <annevk> | in the end XHR will just be a light wrapper around Fetch |
| 10:48 | <annevk> | it's the legacy API for Fetch (history rewritten) |
| 10:48 | <hallvors> | anyway, it's your view that for XHR auth, .withCredentials should only apply to cached stuff (i.e. from earlier manual input)? |
| 10:50 | <annevk> | even that felt somewhat dodgy I've to say |
| 10:50 | <annevk> | having withCredentials for cookies only and just ignoring URL credentials always might be more sensible? |
| 10:51 | <annevk> | ugh |
| 10:51 | <hallvors> | I'd support that |
| 10:51 | <hallvors> | just to simplify implementations.. |
| 10:52 | <annevk> | yeah, I guess we should ask though, how often people use HTTP auth |
| 10:52 | <annevk> | shall I email webapps and do a tweet? |
| 10:53 | <hallvors> | annevk: could you click the lucidchart URL and look at the schema now? |
| 10:53 | <hallvors> | (scroll up for the URL :-p) |
| 10:57 | <annevk> | complex :) |
| 10:57 | <hallvors> | The relevant question is how often people use HTTP Auth *with* XHR, especially cross-origin :-p |
| 10:58 | <hallvors> | ..and how often they use XHR to a HTTP Auth guarded URL *and* want the end user to input user name and password manually (instead of having it hard-coded in the JS) |
| 10:59 | <hallvors> | (Actually it is slightly simplified by removing .withCredentials :)) |
| 10:59 | <darobin> | SteveF: you need to give me the GH accounts of the other editors, unless you can seem to modify access yourself under Setting -> Teams |
| 10:59 | <annevk> | hallvors: ah yes, you'd prolly never want the prompting |
| 11:00 | <SteveF> | darobin:ok thanks will see if not will give you names |
| 11:00 | <hallvors> | I would very much prefer not having to spec any sort of prompting :-p |
| 11:00 | <annevk> | hallvors: okay, so that argues for cross-origin -> yes to go directly to done |
| 11:00 | <annevk> | hallvors: well, we have prompting already |
| 11:01 | <hallvors> | but I don't think XHR+HTTP Auth+prompting is used in the wild |
| 11:01 | <hallvors> | so we could try to kill it |
| 11:01 | <annevk> | I don't think that matter much to be honest |
| 11:01 | <annevk> | and it would be inconsistent with <img> |
| 11:02 | <hallvors> | if it's not about compat , what would stop us from killing it? |
| 11:02 | <annevk> | I don't think we should have such arbitrary differences between <img> and XHR |
| 11:02 | <hallvors> | non-violence preferences at the W3C? |
| 11:02 | <hallvors> | :) |
| 11:02 | <hallvors> | I think IMG and XHR are pretty different |
| 11:02 | <annevk> | not fetch-wise |
| 11:03 | <annevk> | that's the whole point of fetch, to look at these features together |
| 11:03 | <hallvors> | if fetch has impact on UI, it needs to consider what good UI is |
| 11:03 | <annevk> | and not make exceptions because the author of API Y thinks he knows better than the author of API Z |
| 11:03 | <hallvors> | this is probably the only place Fetch requires stuff from the UI |
| 11:03 | <annevk> | there's two places |
| 11:03 | <annevk> | HTTP auth, and HTTP proxy auth |
| 11:04 | <annevk> | and both are because of HTTP being silly |
| 11:04 | <annevk> | and both are legacy |
| 11:04 | <annevk> | and both should not be on/off on a per API basis I think without some proper consideration |
| 11:04 | <annevk> | (and in fact, proxy auth can prolly be never off) |
| 11:04 | <hallvors> | IMO it would make it a lot easier to have good UI if we say that only a top-level URL loaded in a window can trigger auth prompts |
| 11:05 | <annevk> | yes, but legacy |
| 11:05 | <hallvors> | (proxy auth is a bit different.. needs to happen on first request whatever that is) |
| 11:05 | <hallvors> | legacy / compat might require supporting HTTP auth also for main URL in a frame/iframe |
| 11:06 | <hallvors> | (and of course *sending* credentials for IMG et all if within a realm with known credentials) |
| 11:06 | <hallvors> | but I'm pretty sure no compat considerations force us to support prompting for IMG |
| 11:06 | <annevk> | I've encountered cases where the <img> would be behind credentials and the main document would not be |
| 11:06 | <hallvors> | really? |
| 11:07 | <annevk> | yeah, W3C has had stuff like that |
| 11:07 | <annevk> | prolly as legacy as their Overview.html stuff, but still |
| 11:07 | <hallvors> | I've seen bug reports for Opera because it prompted for inline resources and other browsers didn't |
| 11:07 | <hallvors> | we can ignore the W3C |
| 11:07 | <annevk> | oh no |
| 11:07 | <annevk> | all browsers prompt: http://dump.testsuite.org/xhr/auth/ |
| 11:07 | <hallvors> | it's not the real world :-p |
| 11:08 | <hallvors> | weird.. I have certainly seen cases where Opera popped up unexpected prompts and others didn't |
| 11:10 | <annevk> | nice to have someone else care about fetch for a couple of hours though |
| 11:11 | <annevk> | it's been lonely |
| 11:13 | Ms2ger | sends annevk some beer |
| 11:13 | <annevk> | Ms2ger: heh, thanks, but we've got a full fridge of that, no locks |
| 11:15 | <jgraham> | puiblic-script-cood needs a policy that discourages +1 type messages |
| 11:16 | <jgraham> | *public-script-coord |
| 11:17 | <jgraham> | At least I didn't call it public-script-cod-piece |
| 11:17 | <jgraham> | *pubic |
| 11:17 | <hallvors> | argh. can't find the bug(s) I remember |
| 11:17 | <jgraham> | Fuck, now I typod the typo |
| 11:17 | <hallvors> | maybe it was just server side sniffing..? :-( |
| 11:17 | <hallvors> | it's hard to make tpyos deliberatley |
| 11:18 | <Ms2ger> | hallvors, server side sniffing? Surely that would never happen to Opera |
| 11:18 | <jgraham> | Anyway, to recap, messages like "I strongly [dis]agree with X" or "±1" should be considered off topic and subject to censure. |
| 11:19 | <Ms2ger> | Objection! |
| 11:20 | <hallvors> | Ms2ger: I actually expected this to get retweeted more: https://twitter.com/hallvord/status/327322391049019394 :-p |
| 11:20 | Ms2ger | looks at public-script-coord |
| 11:20 | <Ms2ger> | Yeah, no |
| 11:21 | <Ms2ger> | Looks like all the useful threads there are started by bz |
| 11:22 | <hallvors> | Annevk: great if you tweet and E-mail trying to gather some feedback.. |
| 11:24 | <jgraham> | http://www.w3.org/2007/06/PWET-statement-of-principles.html hahaha |
| 11:24 | <jgraham> | "As of 2012, this DOCUMENT IS OBSOLETE, PLEASE SEE OUR NEW CODE (member-only during development, public eventually)" |
| 11:26 | <Ms2ger> | I guess (most of) the W3C does public things like Google does open source |
| 11:47 | <zewt> | Ms2ger: as a PR stunt, with as many roadblocks to prevent people from annoyingly actually using them? |
| 11:47 | <Ms2ger> | Sounds right |
| 11:47 | <zewt> | <- has had a fix for a really annoying bluetooth stack bug in android sitting in a local repo somewhere since like 2.1, way too hard to try to push it upstream |
| 12:25 | <annevk> | hallvors: oh, I think I'm convinced |
| 12:25 | <annevk> | hallvors: but I guess I can email a summary |
| 12:26 | <hallvors> | OK. Honestly, I'm not sure what I convinced you of right now :) |
| 12:26 | <hallvors> | so if you send out a summary I'll have to read it :-D |
| 12:28 | <annevk> | hallvors: well with withCredentials being for cookies, and not using the "authentication entry" or URL credentials for CORS |
| 12:28 | <hallvors> | OK :-) |
| 12:30 | <hallvors> | darobin: w3c-test.org runs PHP as an Apache 2.0 Filter rather than a Handler |
| 12:30 | <hallvors> | maybe there is a bug in PHP's Filter setup? |
| 12:30 | <darobin> | hallvors: you're debugging that with your l33t powers? |
| 12:30 | <darobin> | mmmm, actually that would likely make sense |
| 12:31 | <hallvors> | nah, just committed a phpinfo() file to my pull request ;-) |
| 12:31 | <darobin> | lol |
| 12:31 | <hallvors> | http://w3c-test.org/web-platform-tests/submissions/103/XMLHttpRequest/resources/info.php |
| 12:33 | <darobin> | oooh, great, it has SOAP enabled! |
| 12:43 | <annevk> | so I guess some setting in http://httpd.apache.org/docs/current/filter.html must be wrong |
| 12:57 | <annevk> | hallvors: email sent |
| 12:59 | <annevk> | hallvors: tweet tweeted |
| 12:59 | <annevk> | there's got to be a better way to say that |
| 13:00 | <Ms2ger> | twit twatted |
| 13:01 | <zcorpan> | SteveF: sorry to wontfix your bugs, but really, the focus of html-differences is "differences from html4", not "differences between whatwg and w3c" |
| 13:02 | <SteveF> | zcorpan: no problem |
| 13:02 | <annevk> | +1 to keeping it focused |
| 13:04 | <annevk> | hmm |
| 13:04 | <annevk> | blob URLs |
| 13:04 | <zcorpan> | (listing all differences between whatwg and w3c would be quite useful but should be a separate document) |
| 13:05 | <zewt> | annevk: i'm ... trying, heh |
| 13:05 | <annevk> | yeah, I think SteveF is actually working on that |
| 13:05 | <SteveF> | yes I am |
| 13:05 | <zcorpan> | nice |
| 13:06 | <annevk> | zewt: I dread even opening that thread, but it's one of the last ones I haven't... |
| 13:07 | <zewt> | it's just rehashing the same stuff again |
| 13:09 | <zcorpan> | heh, consensus by general not caring :-) |
| 13:21 | <hallvors> | annevk: "For CORS, we'd return to the caller right there" - what did you mean by this? It sounds like we basically would discard user/pass from open() or URL. |
| 13:22 | <annevk> | hallvors: you don't discard them necessarily, since you'd first do a challenge request and that'll return something and if that's a 401 you just tell the caller that and you never end up using user/pass |
| 13:22 | <annevk> | hallvors: it comes down to the same thing though |
| 13:23 | <hallvors> | But then there is no point in having user/pass arguments in the open() method?? |
| 13:24 | hallvors | this language is too hard, wants the W3C to move towards consensus by dancing |
| 13:24 | <annevk> | hallvors: right, for CORS there wouldn't be |
| 13:25 | <annevk> | hallvors: the only other thing we'd need I guess is a flag in XHR that'd allow you to request that kind of behavior for normal requests too so you don't get a prompt |
| 13:27 | <hallvors> | So you want the only way to do HTTP auth for CORS requests to be to roll your own Authorization header? |
| 13:30 | <annevk> | yes |
| 13:31 | <annevk> | I believe that's currently the case too, in implementations |
| 13:32 | <hallvors> | It's a surprising limitation to authors. |
| 13:32 | <annevk> | zewt: so they met for x hours and still haven't defined dereferencing? *sigh* |
| 13:33 | <hallvors> | at least I think it will cause questions like "why didn't I get access to that CORS-enabled file by passing the right user name and password to open()?" |
| 13:34 | <annevk> | zewt: I think part of the question is "the browser not doing anything with it" |
| 13:34 | <annevk> | zewt: that understanding might be flawed |
| 13:34 | <annevk> | hallvors: haven't seen them thus far |
| 13:48 | <hallvors> | annevk: CORS uptake is good but it's not ubiquitous yet |
| 13:53 | <annevk> | hallvors: yeah we'll have to see |
| 13:56 | <hallvors> | I would still prefer to use user/pass in CORS requests if the server accepts Authorization headers. Seems to be more in line with what authors would expect. As you wanted to treat XHR and <img> the same way, I think doing this would also support your use case with <img> from a different HTTP - auth - protected origin better, no? |
| 13:58 | <annevk> | <img> has a different path |
| 13:58 | <annevk> | tainted cross-origin, XHR cannot get there |
| 13:58 | <annevk> | tainted cross-origin would still do Auth |
| 13:59 | <annevk> | also, what you're saying does not quite work that way, as user/pass would require both preflight and 401, that seems like a hell of a lot of complexity for a marginal case |
| 14:01 | <hallvors> | it would be nice to remove that challenge-response mode too |
| 14:01 | <annevk> | euh |
| 14:01 | <annevk> | that's part of the protocol |
| 14:01 | <hallvors> | and say that if JS provides user/pass we just send it :-p |
| 14:02 | <hallvors> | anyway, at the place in the algorithm we're discussing both preflight and 401 are already done |
| 14:03 | <hallvors> | so the only question is: re-try the request with an Authorization: based on the user/pass the script already gave us.. or give up and return the 401 response to the script? |
| 14:04 | <hallvors> | The complexity is already in the protocol |
| 14:04 | <hallvors> | We're just trying to decide if we're going to push some of the handling of that complexity over to the JS author. |
| 14:14 | <hallvors> | (well, both preflight and 401 are done if we ensure we define this as a request that requires a preflight ) |
| 14:31 | <annevk> | right, the preflight is not done at all |
| 14:33 | <annevk> | it sounds super tricky |
| 14:33 | <annevk> | try to explain it as a set of modifications to Fetch without hurting yourself in the process |
| 14:33 | <annevk> | (sorry for slow reply, had a meeting) |
| 14:35 | <Ms2ger> | Damn meetings :) |
| 14:39 | <annevk> | http://w3cmemes.tumblr.com/post/42434634433/we-welcome-anne-back-to-full-time-wage-slavery |
| 15:14 | <zcorpan> | having looked through the commits for 5.1 for the past 8 months or so, the only things worth noting in html-differences were removal of hgroup and unforking of stuff |
| 15:22 | <dglazkov> | good morning, Whatwg! |
| 19:13 | <MikeSmith> | tantek: I added rel=discussion and rel=issues to the validator code and pushed it to the W3C validator |
| 19:18 | <tantek> | nice. thanks MikeSmith. |
| 20:13 | <Hixie> | as a head's up, i'm gonna be afk most of this month |
| 20:13 | <Hixie> | heads' up? |
| 20:13 | <Hixie> | heads-up? |
| 20:13 | <Hixie> | heads up? |
| 20:23 | <TabAtkins> | heads-up |
| 20:30 | <GPHemsley> | indeed, two words for the verb, one word (or hyphenated) for the noun: log in vs. login, set up vs. set up, etc. |
| 20:30 | <GPHemsley> | although I suppose "heads up" isn't a verb in the traditional sense |
| 20:30 | <GPHemsley> | it's more of a command |
| 20:31 | <GPHemsley> | as in "put your heads up" |
| 20:31 | <GPHemsley> | but anyway |
| 20:31 | <GPHemsley> | the point is the same |
| 20:31 | <GPHemsley> | :) |
| 20:41 | <nimbu> | TabAtkins: if you are celebrating formal friday i have a question for you |
| 20:41 | <nimbu> | TabAtkins: has the idea of using only constants been considered as a step 1 of custom properties. |
| 20:44 | <TabAtkins> | What do you mean by that? Do you mean that the variables can't be mutated by JS? Or do you mean that they're global rather than tree-scoped, so there's no cascade? |
| 20:44 | <nimbu> | TabAtkins: i meant the second |
| 20:45 | <nimbu> | TabAtkins: but i am guessing the first is true for custom properties as they stand no? |
| 20:45 | <TabAtkins> | Custom properties are just properties, so they can be mutated by JS like any other property, yes. |
| 20:45 | <nimbu> | right. |
| 20:46 | <TabAtkins> | The second was of course explored, many times by many people, both inside and outside the CSSWG. It wasn't until I made tree-scoped variables that the WG finally decided they were useful enough to accept. |
| 20:46 | <nimbu> | :|||||| |
| 20:46 | <nimbu> | okay |
| 20:46 | <nimbu> | i wil dig thro the emails |
| 20:48 | <TabAtkins> | See: every single variables proposal *ever* before I finally got mine through. |
| 20:48 | <nimbu> | ahahha |
| 20:48 | <nimbu> | :( |
| 20:48 | <TabAtkins> | Why? |
| 20:49 | <nimbu> | nothingggg |
| 20:49 | <nimbu> | i am just looking |
| 21:53 | <Hixie> | abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=19662#c7 |