| 01:50 | <luxio> | HTML forms should support more HTTP methods like PUT, and also support sending requests with a WWW-Authenticate header |
| 01:50 | <luxio> | Is there a reason these aren't implemented? |
| 01:53 | <luxio> | s/WWW-Authenticate/Authorization |
| 03:34 | <annevk> | Domenic: only indexed properties needed special considerations; bz suggested this setup |
| 03:35 | <annevk> | luxio: not something that enough sites would use and quite complex to add |
| 03:44 | <luxio> | annevk: Not enough sites use authentication? |
| 03:44 | <luxio> | Login is done with POST, and it definitely shouldn't - that's not what the POST method is for. |
| 03:45 | <Domenic> | annevk: I guess I don't remember what's different between indexed and named. And I vaguely remember the idea being that Window was ordinary (no exotic methods needed). |
| 03:48 | <annevk> | Domenic: indexed you need to do the array index dance for; and yeah, we lost ordinary |
| 03:48 | <annevk> | Domenic: we could move it if there's demand |
| 03:48 | <annevk> | luxio: not what I said |
| 03:49 | <luxio> | Perhaps I'm not understanding then - what did you mean to say? |
| 03:49 | <Domenic> | Kind of doubt it matters, but Chrome people were fixing related code and it felt strange to point them to different spec sections for named vs. indexed. |
| 04:02 | <annevk> | luxio: I meant what I said; you generalized from HTTP auth to auth in general |
| 04:03 | <luxio> | annevk: yeah I'm saying sites should use HTTP auth, but they're not able to do that with forms |
| 04:03 | <zewt> | "not what POST is for" sounds like you're interpreting the original concept of HTTP requests, which have very little relevance today |
| 04:04 | <luxio> | zewt: does HTTP not have standards anymore? |
| 04:04 | <luxio> | Why'd they lose relevance? |
| 04:04 | <zewt> | "that's not what the founding fathers intended" reasoning doesn't go very far |
| 04:05 | <luxio> | ignore the first question, is strawman |
| 04:06 | <luxio> | but why'd they change? makes more sense to have those different methods |
| 04:06 | <luxio> | instead of just clumping them all together into POST |
| 04:07 | <zewt> | things change based on how things are actually used, and how they develop over time, and the main things POST means is "don't blindly send this request a second time because it may have side-effects" and "this has a request body" |
| 04:08 | <zewt> | they're clumped together because POST is general purpose, so the protocol doesn't *need* to know special things about something being an authentication request or anything else |
| 04:10 | <zewt> | similarly you almost never see DELETE used in good protocols, since there's no reason at all for HTTP to know that something is abstractly deleting something ... it's just transporting a request |
| 04:11 | <not-an-aardvark> | I disagree, TCP is transporting a request. HTTP is designed to have semantics. |
| 04:14 | <not-an-aardvark> | Generally I would agree that using POST for a bunch of things is probably fine, but I wouldn't say there's "no reason at all for HTTP to know that something is abstractly deleting something". The information seems like it would be useful for caches, etc. |
| 04:14 | <zewt> | there's no benefit for HTTP knowing that something is a deletion (beyond telling clients/proxies not to repeat the request, which you get from POST), it's purely a holdover from before the usage of the protocol was well established |
| 04:15 | <not-an-aardvark> | But DELETE is idempotent and POST is not. Clients and proxies should repeat DELETE requests, but not POST requests. |
| 04:15 | <zewt> | DELETE is definitely not idempotent: if you create a file, send a DELETE request, then create a file in its place, sending that DELETE again is destroying information |
| 04:18 | <not-an-aardvark> | That would apply to PUT too -- if you send a PUT, and then send another request modifying the resource, and then resend the original PUT, you're destroying information. |
| 04:18 | <zewt> | (and more generally, filesystem-like things are much more complex than HTTP methods can represent--there's no RENAME which is just as destructive as DELETE if it overwrites a file) |
| 04:18 | <zewt> | that's the point, the notion of having a bunch of methods to let HTTP know all about your filesystem-like protocol you're putting on top of it doesn't work at all |
| 04:19 | <not-an-aardvark> | Idempotence doesn't apply anyway if someone is modifying the resource between your two requests. |
| 04:19 | <not-an-aardvark> | re. DELETE being idempotent, see https://tools.ietf.org/html/rfc7231#section-4.2.2 |
| 04:20 | <not-an-aardvark> | Anyway I think this discussion is off-topic for this channel so maybe we should take it elsewhere |
| 04:20 | <zewt> | someone can always modify the resource between requests if you send a request twice. |
| 04:40 | <annevk> | Domenic: going to land SAB tests now, will probably land the PR and post later today |
| 10:15 | <annevk> | All done |
| 14:20 | <annevk> | Hmm, at some point Chrome starts returning null from the window getter |
| 14:20 | <annevk> | Cannot invoke open() on null |
| 14:28 | <annevk> | *Gossip Girl voice*: spotted, tobie created a local branch on web-platform-tests |
| 14:29 | <tobie> | What did I do? |
| 14:30 | <annevk> | tobie: I recall you saying you always create remote branches to emulate the experience of new contributors |
| 14:32 | <tobie> | annevk: yeah, used the Web interface to avoid a massive git fetch/rebase |
| 14:36 | <tobie> | annevk: iirc, GH used to let you choose to which repo you'd branch. |
| 14:37 | <tobie> | annevk: seems it no longer the case, so I got lazy. :) |
| 14:44 | <annevk> | It'll be remembered for future arguments 😛 |
| 14:52 | <tobie> | that I get lazy? ;) |
| 20:04 | <Krinkle> | JakeA: igrigorik: Hey. Got a question about preload. As of this week, it's in use on Wikipedia for a simple use case (Main site logo). I'd like to use it more but wonder whether my use case is (or should be) supported. |
| 20:05 | <Krinkle> | We've got a small async script that bootstraps the environment. This url is unversioned and stuck in HTML static cache. That script response than is purged whenever we deploy new code and contains the versioned/immutable urls. I can't add preload for the versioned urls to the HTML response, but I could add them to the async script. I wonder if that's |
| 20:05 | <Krinkle> | supported: Link preload headers on javascript responses. |
| 20:05 | <Krinkle> | It would mean the browser can discover the url much earlier (not after the js download finishes, and executes async/deferred) |
| 20:06 | <Krinkle> | But I get the impression it's HTML only. |
| 20:06 | <Krinkle> | or rather, "page view" only, the same way Link-stylesheet works for image files in Firefox, but obviously only when you're viewing it as its own tab. |
| 21:04 | <Domenic> | Hmm service workers don't control third-party iframes, right? |
| 21:04 | <Domenic> | Otherwise I was hoping to use one to block the tracker requests from Disqus comments (see http://donw.io/post/github-comments/) |
| 21:06 | <TabAtkins> | Domenic: A service worker on yourself (first party)? No, they don't - they'd have to be installed on the third party in the first place to control the iframe. |
| 21:13 | <Domenic> | Yeah, so sad |
| 21:14 | <TabAtkins> | It seems like it would be a pretty major security violation to let your service worker control a third-party domain's loading. ^_^ |
| 21:15 | <Domenic> | True |
| 21:16 | <wanderview> | someone did a thing about trying to use service workers to sanitize requests from a sandbox recently... SW isn't really designed for it |
| 21:19 | <wanderview> | Domenic: this thread: https://twitter.com/freddyb/status/841041787120693251 |
| 23:29 | <Krinkle> | TabAtkins: Although, iirc, service workers do get to intercept/cache script/css/img/fetch requests from the page right? So it doesn't seem *that* weird if iframes would be allowed, too. It'd have to be opaque though. |
| 23:32 | <TabAtkins> | Krinkle: Now that we're talking about requests the iframe'd page is making, not the iframe request itself. |
| 23:32 | <TabAtkins> | *Note |
| 23:33 | <Krinkle> | TabAtkins: Ah, I see. Yeah, makes sense. |