| 00:43 | <railgun> | tantek: no idea, but I know that meta name="author" was used a lot more in the past |
| 00:43 | <railgun> | https://github.com/hakimel/reveal.js/blob/master/demo.html#L10 is one example I could find |
| 00:44 | <tantek> | railgun, I know there is plenty of history of publishing it, I just don't know of any consuming code doing anything with it |
| 00:44 | <tantek> | some web searching made it pretty clear that search engines all ignore it |
| 00:44 | <tantek> | so that's the real question, any consuming code, and in particular, does any browser do anything with it? |
| 00:49 | <railgun> | no idea, but I know that Google uses / has used json-ld to handle data like authors https://developers.google.com/search/docs/guides/intro-structured-data |
| 00:51 | <railgun> | personally I'd prefer meta name="author" over json-ld / link rel="author", but that's not the case... |
| 00:52 | <tantek> | there's plenty of "other" author data that Google handles, whether from microformats, JSON-LD whatever |
| 00:52 | <tantek> | Google used to advocate rel=author, then stopped advocating, and IIRC stopped supporting (though it's harder to verify that) |
| 00:52 | <tantek> | whereas meta name=author they've *never* supported |
| 00:54 | <railgun> | what is the best practice now? |
| 00:55 | <tantek> | what is your objective? |
| 00:56 | <railgun> | I'd like to know the best way to specify the author for a page |
| 00:56 | <tantek> | for whom to consume? |
| 00:58 | <railgun> | hmm it doesn't make as much sense now, but I was thinking about crawlers |
| 11:24 | <JakeA> | @annevk if node wanted to implement fetch(), would you be happy with adding stuff to the spec to let node opt out of CORS & safelist headers etc? |
| 11:43 | <annevk> | JakeA: maybe, depends a bit on the complexity |
| 11:43 | <JakeA> | agreed |
| 11:43 | <JakeA> | Discussion is happening here https://github.com/nodejs/node/issues/19393 |
| 11:50 | <annevk> | JakeA: heh, when I first read that I kinda assumed author was about me, but I guess it wasn't |
| 11:51 | <annevk> | JakeA: I do recall some of those discussions, but perhaps they happened in parallel with someone else |
| 11:54 | <annevk> | I was thinking of replying, but I guess I'll just let it go |
| 11:54 | <annevk> | https://xkcd.com/386/ |
| 12:01 | <JakeA> | annevk: that guy has been historically like that. The "harrasment" he referrs to is when he wanted to have the last word, saying things about fetch that weren't true, and he got annoyed about the corrections. But yeah, 386. |
| 12:59 | <annevk> | lgrahl: fwiw, I think we should reconsider extending WebSocket with streams et al as it reportedly is not going away anytime soon |
| 12:59 | <annevk> | JakeA: ^^ full duplex HTTP breaks on client-side middleware often enough reportedly |
| 13:03 | <lgrahl> | annevk: What's not going away? WebSocket in general you mean? |
| 13:03 | <lgrahl> | annevk: Btw I missed the opportunity to talk to you in person at IETF 101 |
| 13:17 | <annevk> | lgrahl: right, WebSocket in general |
| 13:17 | <annevk> | lgrahl: heh, I was only there briefly |
| 13:18 | <lgrahl> | annevk: So... do I understand you correctly that you would like to backport streams to WebSocket once we have them for data channels? |
| 13:19 | <wanderview> | annevk: JakeA: at least in firefox we have a super-user type origin that can use fetch that might also benefit from better spec support in this area |
| 13:19 | <wanderview> | I wonder what nodejs considers its base URL |
| 13:20 | <annevk> | lgrahl: yeah, something like that |
| 13:21 | <annevk> | lgrahl: it's at least something we should consider doing again now it's clear that full duplex HTTP cannot be deployed at scale |
| 13:21 | <lgrahl> | annevk: Yeah, that makes sense. Especially because in the WS case we can model it as a pull source and handle backpressure... which we can't at the moment. |
| 13:23 | <lgrahl> | annevk: Maybe you can have a quick look at my question from two days ago: https://freenode.logbot.info/whatwg/20180325#c1478416 |
| 13:24 | <annevk> | lgrahl: I saw that, but I don't know; perhaps wanderview or JakeA do |
| 13:24 | <wanderview> | lgrahl: if they are pull streams "pausing" just means that you stop pulling, right? |
| 13:25 | <lgrahl> | wanderview: Yep. But I can't stop pulling on individual streams, just the whole association. |
| 13:27 | <wanderview> | lgrahl: that must be something other than a streams spec issue? I'm not aware of anything in streams that groups multiple streams into a bundle or whatever |
| 13:27 | <lgrahl> | wanderview: It's not a spec issue. It's rather a question of how to apply the streams spec in this case. |
| 13:27 | <wanderview> | closest thing might be the clone() operation |
| 13:28 | <wanderview> | where you end up with two ReadableStreams tee'd off the same source |
| 13:28 | <wanderview> | and one is read, but the other is not |
| 13:28 | <wanderview> | in this case the browser ends up having to buffer the difference in read rates |
| 13:28 | <wanderview> | which may or may not be a reasonable thing for webrtc... |
| 13:29 | <wanderview> | sorry... not clone()... that is fetch spec... the streams spec thing is tee() |
| 13:29 | <lgrahl> | Ah, okay, so the SCTP streams aren't WHATWG streams. It's a feature of SCTP. |
| 13:30 | <lgrahl> | Basically, SCTP allows you to multiplex multiple SCTP streams. I'm trying to map them to WHATWG streams with the mentioned technical limitation. |
| 13:31 | <wanderview> | lgrahl: if there is no way to apply back pressure to individual streams, but only to all of them at once... it seems like you need an extra thing in the API that says "if any of these streams becomes blocked the entire group will be paused" |
| 13:32 | <wanderview> | I don't really know the use cases, etc |
| 13:34 | <lgrahl> | wanderview: That could deadlock the association. We could either treat them as push sources and not handle backpressure at all or say "if all of the streams are blocked, the entire assoc will be paused". My question would be if the latter would play well with WHATWG streams. |
| 13:35 | <wanderview> | lgrahl: not handling back pressure and not pausing the source will lead to exhausting memory, no? |
| 13:35 | <lgrahl> | wanderview: It does but without any per-stream flow control I don't see a way around it |
| 13:36 | <wanderview> | lgrahl: ok... sounds like a footgun, though |
| 13:36 | <lgrahl> | wanderview: It's much more of a footgun at the moment, so it's an improvement. :] |
| 13:36 | <wanderview> | lgrahl: I guess we do the same thing for http1.x network response bodies... |
| 13:36 | <wanderview> | lgrahl: the difference is those tend to be of bounded size... its unclear to me how much data your streams are going to be pushing |
| 13:37 | <lgrahl> | wanderview: Technically unlimited |
| 13:38 | <lgrahl> | wanderview: We thought about a per-stream flow control extension to SCTP... but that is very prone to deadlocks, so nobody wants to touch that subject. I wonder how the QUIC people do it... |
| 13:39 | <wanderview> | lgrahl: h2 supports it |
| 13:39 | <wanderview> | it has its own framing protocol, though |
| 13:43 | <lgrahl> | wanderview: Anyway, the common use case will be some control stream on one side and some file stream on the other side. So, while the backpressure issue is going to be annoying if someone sends really fast, it's still a huge advantage to be able to handle chunks early and write them to disk on-the-fly. |
| 13:43 | <wanderview> | ok |
| 13:43 | <wanderview> | lgrahl: that sounds reasonable... I guess I was worried it was video data or something |
| 13:44 | <lgrahl> | wanderview: It does compete with A/V but that falls into a whole other category (congestion control - not my department) :) |
| 13:44 | <lgrahl> | And so does it today FWIW |
| 13:45 | <wanderview> | lgrahl: thats fine... I was worried about buffering video data |
| 13:45 | <lgrahl> | wanderview: People could technically run custom video codecs over it... so it's good you're mentioning this. |
| 13:46 | <wanderview> | lgrahl: maybe it would be worth adding some kind of event like "excessive buffering OMG" that people could listen for? I don't know if that would be used or worth it, though |
| 13:48 | <lgrahl> | wanderview: You can already query the amount of buffered data with the current API. We could use that in streaming mode to get the amount of backlogged data. But the question would be if that's helpful... people could run their own flow control but that's really meh. |
| 13:49 | <wanderview> | lgrahl: if you want to support that API, you probably need to keep the streams spec streams as pull sources... so you know how much is buffered and can report it... if you push it into the ReadableStream I'm not sure you can see how much is buffered there |
| 13:52 | <lgrahl> | wanderview: I'll look into this. But exposing it via https://rawgit.com/w3c/webrtc-pc/master/webrtc.html#dom-rtcdatachannel-bufferedamount would be an ok-ish fallback to me if that's too much effort. |
| 14:59 | <domfarolino> | annevk: Does fetch allow for redirecting across schemes? |
| 14:59 | <annevk> | domfarolino: not generally |
| 15:00 | <domfarolino> | annevk: Ok, would you say https://crbug.com/532782 (redirecting to a Blob URL) is probably a non-issue? |
| 15:01 | <domfarolino> | As Kinuko says at the bottom of thread spec doesn't really talk about this, and from what I see, there's only https://fetch.spec.whatwg.org/#http-redirect-fetch which wouldn't support this |
| 15:01 | <wanderview> | its basically a cross-origin redirect, right? |
| 15:02 | <wanderview> | don't some browsers explicitly block redirect to data URLs? |
| 15:11 | <domfarolino> | wanderview: It seems that Chrome does yeah. Is this mandated by spec? |
| 15:13 | <wanderview> | domfarolino: I believe we block it from insecure http redirect now... not sure where the spec stands these days |
| 15:15 | <domfarolino> | wanderview: Does that mean the redirect is not blocked if it's coming from https? |
| 15:17 | <wanderview> | domfarolino: actually, looks like we blocked on subresource redirects to data URLs here... https://bugzilla.mozilla.org/show_bug.cgi?id=1428793 |
| 15:17 | <wanderview> | FF60 |
| 15:17 | <wanderview> | which is beta atm |
| 15:32 | <domfarolino> | wanderview: Ahh ok thanks for the info |
| 15:32 | <domfarolino> | wanderview: So should a Blob URL be treated the same as a data URL then? honestly I'm not entirely familiar with either (or their differences) |
| 15:33 | <wanderview> | domfarolino: so... I'm not even sure how a server would legit get a blob URL since it consists of an ephemeral hash specific to a particular browser instance running in the client |
| 15:34 | <wanderview> | domfarolino: I guess a service worker could return a redirect to a blob URL, but it could also just respondWith() the blob as a response |
| 15:34 | <wanderview> | domfarolino: my inclination would be to block redirects to "local" urls which would covert data:, blob:, about:, etc... not sure what annevk thinks about that, though |
| 15:35 | <annevk> | domfarolino: per the spec that's a network error I think |
| 15:35 | <annevk> | domfarolino: now if you navigate to the URL, it would work... |
| 15:36 | <annevk> | domfarolino: that's what I meant with not generally; when navigating you can be redirected to non-HTTP(S) URLs |
| 15:36 | <annevk> | wanderview: you can include it in the URL, which is a little silly |
| 15:36 | <wanderview> | annevk: include what? |
| 15:36 | <annevk> | wanderview: the blob URL |
| 15:37 | <wanderview> | annevk: oh... as a search param that gets reflected... like how our various tests work |
| 15:37 | <annevk> | wanderview: "redirectme?url=" + blobURL or some such |
| 15:37 | <wanderview> | annevk: yea... I guess that woudl work... but happy to network error that |
| 15:38 | wanderview | lunches |
| 15:43 | <domfarolino> | annevk: Ok so as per https://fetch.spec.whatwg.org/#ref-for-concept-response-location-url%E2%91%A3, any redirect through fetch() to a non http(s) should be a network error as you mentioned |
| 15:43 | <domfarolino> | annevk: but on navigations it can work and that's fine |
| 15:47 | <domfarolino> | thanks for the info! |
| 15:47 | <annevk> | domfarolino: for navigations HTML controls what's allowed |
| 15:48 | <domfarolino> | Right that makes sense |
| 15:48 | <annevk> | domfarolino: it seems that "blob" is disallowed there |
| 15:48 | <annevk> | > Otherwise, if response has a location URL that is a URL whose scheme is "blob", "file", "filesystem", or "javascript", then set response to a network error. |
| 15:50 | <domfarolino> | Ahh was just looking for that, thanks |
| 16:31 | <wanderview> | annevk: hasn |
| 16:31 | <wanderview> | hasn't top level data URL navigation also been blocked now? |
| 16:32 | <wanderview> | also, I'm confused... blob: URL is allowed as an iframe html load AFAIK |
| 16:35 | <domfarolino> | wanderview: FF doesn’t block top level data URL navigation from what I see, same with Blob. I don’t think HTML spec blocks it either |
| 16:50 | <annevk> | wanderview: top-level blocking isn't specced, this is also not blocking navigation in general, just redirects while navigating |
| 16:50 | <annevk> | wanderview: does that help? |
| 16:50 | <wanderview> | ah... I missed that you were only quoting a line about redirection |
| 17:54 | <domfarolino> | annevk: Should top-level request redirecting from HTTP(S) => data:... behave differently HTTP(S) => HTTP(S) => data:... ? |
| 17:54 | <domfarolino> | HTML Standard seems to make them behave differently, since for the second one, HTTP-Redirect Fetch is called which doesn't allow redirects to anything but another HTTP(S) scheme |
| 19:01 | <domfarolino> | woops nevermind, wasn't reading it right :( |
| 19:39 | <annevk> | “manual” is key here 😊 |