| 04:07 | <Domenic> | Mounir_: Honestly I would rather have .screenAngle and .screenType at this point if abarth is going to block on introducing a record. |
| 04:29 | SamB | records Domenic's statement in his logfiles |
| 06:57 | <ManishCloud> | annevk: Oh, so you can only fetch HTTP(s). Alright, thanks. This deviates from the actual implementation in Gecko/Blink a bit, but no problem |
| 06:57 | <annevk> | ManishCloud: no you can't |
| 06:57 | <ManishCloud> | ? |
| 06:57 | <annevk> | ManishCloud: #concept-fetch handles all URL schemes |
| 06:58 | <annevk> | ManishCloud: and defines the security policy for all of them too |
| 06:58 | <annevk> | ManishCloud: however, CORS is an HTTP protocol |
| 06:58 | <ManishCloud> | it handles data and about |
| 06:58 | <ManishCloud> | and http(s) |
| 06:58 | <annevk> | ManishCloud: so only the parts of #concept-fetch that end up in the HTTP pipeline will do CORS |
| 06:58 | <annevk> | ManishCloud: and blob and ftp and file |
| 06:58 | <annevk> | ManishCloud: and soon filesystem |
| 06:59 | <annevk> | ManishCloud: a proper implementation of XMLHttpRequest is built on top a proper implementation of Fetch |
| 06:59 | <ManishCloud> | yep |
| 07:01 | <SamB> | annevk: of course, CORS is totally beside the point for data: URLs anyway, yes? |
| 07:01 | <ManishCloud> | I still don't see any rule for ftp. It handles data, then about, then some request modes, then it says that non-http/https should return a network error |
| 07:01 | <ManishCloud> | SamB: strangely enough Blink doesn't seem to allow fetching of data |
| 07:01 | <annevk> | ManishCloud: it depends on the request mode |
| 07:02 | <annevk> | ManishCloud: if you're only considering XMLHttpRequest, then yes, XMLHttpRequest can only Fetch ftp if from an ftp URL (as then they're same-origin) |
| 07:02 | <ManishCloud> | okay |
| 07:02 | <annevk> | ManishCloud: but e.g. <img>'s request mode is "No CORS" by default, and therefore can fetch ftp all the time (although it would end up being a tainted response) |
| 07:03 | <annevk> | SamB: yeah, it's not entirely inconceivable that we add CORS things to non-HTTP schemes, but I kind of doubt it |
| 07:04 | <ManishCloud> | oh, I see |
| 07:04 | <SamB> | annevk: well, with data: the data is all in the URL anyway so it's totally pointless, no? |
| 07:04 | <SamB> | no information leakage is possible, as the information is pre-leaked |
| 07:07 | <annevk> | SamB: yeah |
| 07:07 | <ManishCloud> | annevk: in case of an <img> it's an opaque taint, though. Isn't opaque almost the same as a network error? |
| 07:07 | <ManishCloud> | (how does that work) |
| 07:08 | <annevk> | ManishCloud: the implementation of <img> has special privileges in that it can access the internal response to decode the bytes returned and leak some information through width/height |
| 07:08 | <annevk> | ManishCloud: that's a bit of a legacy bug |
| 07:08 | <SamB> | annevk: it doesn't also tell you if the load outright failed? |
| 07:08 | <annevk> | SamB: it does? |
| 07:08 | <SamB> | I don't know |
| 07:09 | <annevk> | I'm not sure what you're asking |
| 07:09 | <SamB> | I guess you could guess pretty well though |
| 07:09 | <SamB> | if the placeholder image has a predictable width/height ... |
| 07:10 | <annevk> | SamB: if fetch returns a network error <img> will dispatch an error event |
| 07:10 | <SamB> | that's what I was thinking of, yes |
| 07:10 | <annevk> | With legacy APIs you can definitely distinguish between tainting and network errors, it's a bit of a bug that's been exploited all over |
| 07:10 | <ManishCloud> | annevk: Oh, I see. |
| 07:11 | <SamB> | how hard can you exploit that? |
| 07:11 | <SamB> | doesn't seem as bad as the old :visited problem ... |
| 07:12 | <SamB> | oh, you know what I hate? auth dialogs for <img>s |
| 07:12 | <ManishCloud> | :o |
| 07:14 | <SamB> | there was this one thing that tried to load favicons from a bunch of domains, I think the idea was to see if your ISP was blocking any of them? |
| 07:14 | <SamB> | but some of them popped up those stupid dialogs :-( |
| 07:14 | <annevk> | Authentication dialogs can be spawn from pretty much any API |
| 07:14 | <ManishCloud> | SamB: imagine what happens when you're behind a misconfigured authenticated HTTP proxy |
| 07:14 | <annevk> | Only the very newest of APIs have that disabled |
| 07:15 | <SamB> | might be nice to rate limit them or something ;-) |
| 07:15 | <ManishCloud> | has happened to me. They broke login; usually after a couple of failed logins it returns an html error page. But if there are many images, well, boom. |
| 07:16 | <annevk> | SamB: you can figure out whether someone has an account with a certain site (the problem is made worse due to sending cookies along with the request, but it essentially exists because the user resides on a different IP than the server) |
| 07:16 | <SamB> | annevk: hmm |
| 07:17 | <SamB> | so, like, do they have a met-art account or whatever |
| 07:17 | <SamB> | maybe something a bit more embarrassing |
| 07:20 | <annevk> | Or if your government is hostile and tries to track which organizations you are affiliated with... |
| 07:20 | <SamB> | true |
| 07:21 | <annevk> | ManishCloud: you're implementing this for Servo? |
| 07:21 | <SamB> | that's what he said |
| 07:21 | <ManishCloud> | annevk: CORS? sort of |
| 07:21 | <annevk> | ManishCloud: I recommend implementing Fetch |
| 07:21 | <ManishCloud> | annevk: So I'm writing it XHR-specific but I intend to integrate this into Teepee (a full Rust implementation of fetch.s.w.o) later |
| 07:22 | <annevk> | s.w.o? |
| 07:22 | <ManishCloud> | spec.whatwg.org |
| 07:22 | <annevk> | heh |
| 07:22 | <ManishCloud> | Teepee intends to implement the fetch spec (not the browser specific things like Request and fetch() ) |
| 07:23 | <annevk> | Pointer to GitHub? |
| 07:23 | <ManishCloud> | As far as implementing fetch() in Servo, I'll do that when Teepee is stable; no point implementing it with rust-http when I'll have to do all the plumbing that Teepee plans to do all over again |
| 07:23 | <ManishCloud> | annevk: https://github.com/teepee/teepee |
| 07:23 | <annevk> | Sounds good I guess, as long as you guys have the better picture in mind |
| 07:24 | <annevk> | I don't really care about fetch() |
| 07:24 | <ManishCloud> | annevk: then? |
| 07:24 | <annevk> | I mostly care about Fetch |
| 07:24 | <ManishCloud> | oh, #concept-fetch |
| 07:24 | <annevk> | That <img>, XMLHttpRequest, background-image, etc. all call into the same library to get a bag of bits |
| 07:24 | <ManishCloud> | Teepee ought to solve that problem |
| 07:24 | <annevk> | After that fetch() is relatively straightforward |
| 07:25 | <ManishCloud> | Exactly, that's why I haven't implemented it yet ;p |
| 07:26 | <annevk> | If Teepee is a generic HTTP toolkit, they might not be okay into making it something specific to clients |
| 07:26 | <ManishCloud> | I'm not the maintainer of Teepee, but I believe that it should be easy to just do `let req = Request::new(method, url, header, mode, blah)` and then call `req.fetch()` or something (with channels/hooks for the task queues) |
| 07:26 | <ManishCloud> | annevk: it has both a client and server library. As well as some common stuff (like headers/methods) |
| 07:27 | <ManishCloud> | It's not for browser specific stuff, but most of the spec isn't browser specific |
| 07:27 | <annevk> | Why would an HTTP library be interested in data URLs? |
| 07:27 | <annevk> | Or service workers? |
| 07:27 | <ManishCloud> | Good point |
| 07:27 | <annevk> | Or CORS? |
| 07:28 | <ManishCloud> | I need to discuss this with Chris as well, but first I'll try to get CORS done. If Chris doesn't want #concept-fetch, I'll write a wrapper for Teepee |
| 07:28 | <ManishCloud> | annevk: he said he does want CORS |
| 07:28 | <ManishCloud> | one sec |
| 07:28 | <annevk> | Oh |
| 07:28 | <annevk> | Fetch is basically a big superset of a client-side HTTP library with some tweaks |
| 07:29 | <annevk> | And these days JavaScript hooks (service workers) |
| 07:29 | <ManishCloud> | annevk: https://botbot.me/mozilla/rust/2014-06-30/?msg=17205109&page=9 |
| 07:30 | <ManishCloud> | yep |
| 07:31 | <annevk> | I guess you can guys can sort out the planning, now you know how it works |
| 07:34 | <ManishCloud> | yep :P |
| 07:34 | <ManishCloud> | :) |
| 07:38 | <ManishCloud> | anyway, thanks for the help! |
| 09:29 | <annevk> | tobie: asURL() still seems simplest, the others get tricky; e.g. request has an origin that won't be the origin of the URL |
| 09:29 | <annevk> | tobie: at least not always |
| 10:25 | <hsivonen> | MikeSmith: I'll need to figure out how to deploy from git first. Not going to happen today. Tomorrow hopefully. |
| 10:27 | <MikeSmith> | hsivonen: no rush then. Tomorrow's a US holiday anyway, so a lot of people would miss any announcement. So it can wait til next week or after. |
| 11:14 | <annevk> | Ms2ger: should we revive the thing where we use a single entry to reference a bunch of specs? |
| 11:14 | <annevk> | Ms2ger: seems somewhat useful for XML, but especially HTTP |
| 11:14 | <Ms2ger> | Mm, perhaps |
| 12:30 | <crankharder> | so i'm working with this 3rd party / client that is sending us multi-part POST requests that have no Content-Length which has already caused problems where akamai immediately drops the request ( ddos protection etc ) |
| 12:30 | <crankharder> | is there any scenario where not specifying the content-length is valid or should I be pushing back on these guys about the finer points of the http spec? |
| 12:48 | <annevk> | crankharder: https://tools.ietf.org/html/rfc7230#section-3.3.2 |
| 12:48 | <Domenic> | crankharder: I believe if you specify Transfer-Encoding: chunked and the data gets sent in that fashion, Content-Length is not necessary |
| 13:04 | <crankharder> | I just managed to get my hands on the raw request: 'Transfer-Encoding: chunked' |
| 13:04 | <crankharder> | dammit |
| 13:05 | <annevk> | crankharder: seems like an Akamai problem |
| 13:15 | <zewt> | the whole point of chunked is to not specify a content length, you use it when you don't know the length in advance |
| 13:16 | <zewt> | eg. compression |
| 14:38 | <tobie> | annevk: not sure that bug's comment is the right place to have the URL conversation. :) |
| 14:39 | <tobie> | annevk: happy to take that elsewhere if you want. |
| 14:40 | <annevk> | tobie: so you want URL.parse to return an immutable object? |
| 14:42 | <tobie> | annevk: no. I'm just expressing confusion as to why we on one hand facilitate devs building URL objects and on the other, hope they use strings to represent urls as much as possible. |
| 14:42 | <annevk> | If we had value objects sooner URLs would be a value object |
| 14:43 | <annevk> | However, we don't, so they are strings. Similarly time representation is done through a floating point number. |
| 14:43 | <tobie> | annevk: I need to refresh my memory about those. |
| 14:43 | <annevk> | Meaning can be extracted through objects such as URL and Date |
| 14:44 | <tobie> | annevk: everybody agrees that the Date constructor in JS is terrible. |
| 14:44 | <tobie> | annevk: also mutable dates kind of blow my mind (but that's more subject to debate). |
| 14:45 | <annevk> | tobie: the constructor being terrible does not mean it's not the way to do time |
| 14:46 | <annevk> | Anyway, the underlying platform model thing is a URL value object of sorts |
| 14:47 | <annevk> | Which is serialized when you do request.url |
| 14:50 | <tobie> | annevk: mmm. Well, we're going on in circles, here, but given it's stringifiable(?) why don't we expose this as an immutable URL object then? |
| 14:50 | <annevk> | tobie: that doesn't exist |
| 14:50 | <annevk> | tobie: or do you mean the URLUtilsReadOnly thing? |
| 14:51 | <annevk> | tobie: yeah, I wouldn't mind doing that |
| 14:51 | <annevk> | tobie: on reflection, Domenic seemed opposed somewhat |
| 14:51 | <tobie> | annevk: no I mean the stringifier attribute. |
| 14:52 | <tobie> | annevk: (but I might be misunderstanding what it means.) |
| 14:52 | <annevk> | tobie: you lost me |
| 14:54 | <tobie> | annevk: :( God I hate WebIDL. |
| 14:55 | <Ms2ger> | It's always easy to blame WebIDL |
| 14:55 | <annevk> | tobie: I'm happy with an explanation that does not involve IDL |
| 14:58 | <tobie> | annevk: wondering if all of this doesn't stem from my misunderstanding of what stringifier does. |
| 14:58 | <tobie> | annevk: reading up on it now. |
| 14:58 | <tobie> | Ms2ger: heh. |
| 14:58 | <annevk> | tobie: that's just another word for toString() |
| 14:59 | <tobie> | annevk: right. So the URL object gets turned into url.href when coerced to a string, right? |
| 14:59 | <annevk> | yes |
| 15:05 | <tobie> | annevk: I guess I need to see more examples of SW before pushing for a change here. |
| 15:06 | <tobie> | annevk: if it is mostly the case that people use request.url to choose how to respond, then returning an immutable URL object makes sense. |
| 15:07 | <tobie> | annevk: if on the other hand, there's lots of manipulation of the URL object going on anyway, then we might as well keep the string. |
| 15:08 | <annevk> | tobie: changing this after the fact will be hard |
| 15:09 | <annevk> | tobie: at least in a nice way |
| 15:11 | <tobie> | annevk: vaguely related, but you mentioned the Request object has an origin attribute. Where is it defined? (can't find it) |
| 15:11 | <tobie> | annevk: true. I meant I want to look at a bit more examples. |
| 15:11 | <tobie> | Within the next couple of weeks. |
| 15:13 | <annevk> | tobie: oh, it's not exposed |
| 15:14 | <annevk> | tobie: I think it might not be exposed because it would always be same-origin with the service worker |
| 15:14 | <annevk> | tobie: I kept some properties off Request for now until we have a v0 implementation |
| 15:15 | <annevk> | tobie: yeah, I guess we can change this in August still |
| 15:18 | <tobie> | Right, that was my understanding wrt that origin prop. |
| 15:42 | <tobie> | annevk, JakeA: is the promise returned by cache.add resolved with responseArray or void? Promise<any> seems to imply the former, the algorithm seems to imply the latter. |
| 15:47 | <tobie> | annevk, JakeA: Trying to build an example which primes the cache after a cache miss: https://gist.github.com/tobie/0689c5dda8f6d49d500d#file-gistfile1-js-L25-L30 |
| 15:50 | <annevk> | not sure, haven't followed Cache that much |
| 15:50 | <annevk> | waiting for rename, some more stability in the API |
| 15:53 | <tobie> | cache.add which does fetch in the background seems like a terrible name (and weird API) |
| 15:54 | <tobie> | annevk: also priming the cache before sending back a response shouldn't be that difficult. |
| 15:58 | <annevk> | tobie: work on it with Jake? |
| 15:59 | <tobie> | annevk: if that's how it works, then sure. :) |
| 15:59 | <annevk> | tobie: I think JakeA is working on that API and making sure it's good |
| 15:59 | <annevk> | If that's not the case I'd like to know, because then someone else should take ownership |
| 16:06 | <tobie> | annevk: reaching out to JakeA by email, cc'ing you. |
| 16:07 | <tobie> | annevk: or should I move that conversation to WHATWG mailing list directly? |
| 16:07 | <annevk> | tobie: public-webapps is the SW spec list, and since cache is there... |
| 16:08 | <tobie> | annevk: ty |
| 16:10 | <tobie> | annevk: what about the waitUntil/respondWith issue? |
| 16:11 | <annevk> | tobie: could email there too, it's hard to attract people that want to change that part of the design |
| 16:11 | <annevk> | tobie: probably need to come up with a replacement design to get that through |
| 16:11 | <tobie> | I have for waitUntil |
| 16:12 | <tobie> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/256#issuecomment-47878042 |
| 16:53 | <IZh> | Hi. Is there API to specify which textarea should or shouldn't be spell checked by browser (if capable)? |
| 16:53 | <IZh> | And probably suggest language for checking. |
| 16:56 | <IZh> | May be for other types of input fields too. |
| 16:59 | <gsnedders> | is the script that generates the index published anywhere? |
| 17:00 | <gsnedders> | IZh: the spellcheck attribute |
| 17:00 | <IZh> | gsnedders: thanks. |
| 17:00 | <gsnedders> | IZh: language I guess is inferred from @lang? |
| 17:00 | <gsnedders> | but browsers may just always assume the current locale |
| 17:02 | <IZh> | gsnedders: May be. But it will be bad for online translator sites. |
| 17:10 | <Ms2ger> | gsnedders, assuming not, given that it's part of Hixie's pipeline |
| 17:11 | <Hixie> | there's no script that generates the index |
| 17:11 | <Hixie> | it's manually managed |
| 17:12 | <gsnedders> | Hixie: oh, okay |
| 17:24 | <jgraham> | gsnedders: So you can have access to it, but only if you have a scapel |
| 17:40 | <jgraham> | Is there a proper way to select the elements of the first column of a table (:nth-child doesn't seem to work in the face of cells with rowspan > 1)? |
| 17:41 | <Ms2ger> | No |
| 17:42 | jgraham | adds a class |
| 17:44 | <jgraham> | Hmm, it will also screw up alternating row background colours because the first column will get a random colour |
| 17:47 | <Hixie> | many people have over the years proposed table-model-aware selectors |
| 20:11 | <annevk> | Imagine if all those people instead worked on the table layout model... Oh wait |
| 20:15 | <jgraham> | Only dbaron actually understands the table layout model |
| 20:15 | <jgraham> | Although he does try to explain it to everyone he meets |
| 20:16 | <jgraham> | Which does mean that one day a second person might understand it |
| 20:19 | svl | is reminded of http://quotes.burntelectrons.org/183 |
| 20:52 | <annevk> | There's some brilliant quotes there |
| 21:02 | <annevk> | I should probably stop reading now |
| 21:04 | <svl> | ^_^ |
| 21:56 | <cabanier> | annevk: yeah! It makes my sadness for the depressing state of the geometry interfaces go away |