| 01:01 | <MikeSmith> | hsivonen: ^ |
| 10:30 | <annevk> | Domenic: added a bunch of README.md files |
| 10:49 | <MikeSmith> | annevk: hey so for URL should we just drop the canonicalization tests from the wpt test suite or is what's in there now OK (I mean after the cleanup you did) |
| 10:59 | <annevk> | MikeSmith: hmm I missed those |
| 11:00 | <annevk> | MikeSmith: what is canonicalization testing? just serializing? |
| 11:03 | <MikeSmith> | annevk: Yeah it's only relevant to serialization afaict |
| 11:03 | <annevk> | MikeSmith: I guess we should at least rename it then |
| 11:04 | <annevk> | MikeSmith: we might at some point define a normalization/canonicalization algorithm I suppose that does certain things |
| 11:07 | <MikeSmith> | annevk: are those tests checking anything that's actually specified in the spec? |
| 11:09 | <annevk> | MikeSmith: looking |
| 11:10 | <annevk> | MikeSmith: what tests are you referring to exactly? |
| 11:12 | <MikeSmith> | annevk: the ones you cleaned up in https://github.com/w3c/web-platform-tests/commit/3c5a8de5b0cd49033fd6ef0954cc802b7682c769 |
| 11:12 | <annevk> | MikeSmith: oh yes, they are |
| 11:12 | <MikeSmith> | annevk: OK good |
| 11:12 | <MikeSmith> | annevk: I was confused |
| 11:13 | <annevk> | Compared to RFC 3986 URL parsers in browsers do a fair bit of "normalization" / "canonicalization" right in the parser |
| 11:13 | <annevk> | E.g. something like lowercasing the scheme or the domain |
| 11:18 | <annevk> | MikeSmith: if I update the README file of the URL tests, can I do that without PR? |
| 11:19 | <MikeSmith> | annevk: yeah sure |
| 11:21 | <MikeSmith> | annevk: btw I guess it could be argued that RFC 3986 does actually implicitly deal with normalization/canonicalization by e.g., saying that the host and scheme should be compared case-insensitively |
| 11:22 | <MikeSmith> | annevk: though of course it doesn't specify parsing per se |
| 11:25 | <annevk> | MikeSmith: it also says %AA and %aa are identical, but it does not say what you have to transmit to the server based on what input |
| 11:25 | <MikeSmith> | ah ok |
| 11:26 | <annevk> | MikeSmith: so you can say HTTP is equal to hTTp when it's a scheme, but that does not answer what e.g. .protocol will return |
| 11:26 | <annevk> | MikeSmith: we could of course assume the parser does none of fixing up and instead define what needs to happen at all the end points |
| 11:26 | <MikeSmith> | right, I see now |
| 11:27 | <annevk> | but that seems less straightforward (it's kind of what CSS sometimes does, and it's a bit annoying when defining the CSSOM) |
| 14:21 | <Manishearth> | annevk: around? |
| 14:22 | <Manishearth> | Possible problem with the XHR spec |
| 14:28 | <Manishearth> | Compare it with the w3c spec |
| 14:28 | <Manishearth> | http://www.w3.org/TR/XMLHttpRequest2/#the-abort-method |
| 14:28 | <Manishearth> | if you see step 3, it also removes tasks in the DOM task queue related to the XHR object |
| 14:29 | <Manishearth> | the WHATWG spec only says that the fetch algorithm should be terminated |
| 14:29 | <Manishearth> | which doesn't terminate any queued load events |
| 14:30 | <Manishearth> | eg lets say the XHR object changes state to LOADING |
| 14:30 | <Manishearth> | and in the readystatechange handler, we invoke abort() |
| 14:30 | <Manishearth> | however, before doing so, we perform a heavy computation |
| 14:31 | <Manishearth> | so that the XHR finishes loading and queues a https://xhr.spec.whatwg.org/#handle-response-end-of-file event to the queue |
| 14:31 | <Manishearth> | now we do abort() |
| 14:31 | <Manishearth> | changing the state to unsent |
| 14:32 | <Manishearth> | after abort(), within the same handler, we call open() and send() again |
| 14:33 | <Manishearth> | that response-end-of-file event for the previous file will be processed after this |
| 14:33 | <Manishearth> | so we'll get the end of the previous file instead of the new file |
| 14:36 | <gsnedders> | is it possible to have an arbitrary domain forwarding all email to Gmail in the normal way through Postfix nowadays? My domain seems to constantly get IP blocked by Gmail beause of an "unusual rate of spam" |
| 15:03 | <GPHemsley> | gsnedders: Well quit spamming, then! |
| 15:22 | <gsnedders> | GPHemsley: but but but I don't send anything from that SMTP server! |
| 15:22 | <GPHemsley> | gsnedders: Well quit anti-spamming, then! |
| 15:22 | <gsnedders> | bah! |
| 16:10 | <annevk> | Manishearth: hmm, file a bug? |
| 16:12 | <Manishearth> | annevk: I'll do that, but do you think it's an issue or did I misinterpret the spec? |
| 16:13 | <Manishearth> | (probably tomorrow) |
| 16:22 | <annevk> | not sure |
| 21:14 | <terinjokes> | is there any other spec that has a bunch of methods that do effectively the same thing? |
| 21:19 | <annevk> | terinjokes: these are quite similar: https://fetch.spec.whatwg.org/#body |
| 21:20 | <terinjokes> | annevk: indeed, and what I was thinking "must be the result of running <<logger>> with <<blah>>" |