Wednesday, October 5, 2022< ^ >
Martin Thomson has set the subject to:
Room Configuration
Room Occupants

[21:00:02] <zulipbot> (Roy Fielding) well, this is exciting.
[21:00:23] <zulipbot> (Julian Reschke) the suspense!
[21:00:36] <zulipbot> (Daniel Stenberg) =)
[21:01:46] <zulipbot> (Julian Reschke) si
[21:01:59] <zulipbot> (Chris Lemmons) Indeed we can.
[21:02:00] <zulipbot> (Daniel Stenberg) can hear
[21:04:31] <zulipbot> (Martin Thomson) I am on codimd scribing now.
[21:04:52] <zulipbot> (Tommy Pauly)
[21:05:05] <zulipbot> (Tommy Pauly) For people to get to the notes
[21:05:05] <zulipbot> (Martin Thomson) I will do it.
[21:05:18] <zulipbot> (Justin Richer) I can help with patch and edits if we're doing it in hedgedoc
[21:05:35] <zulipbot> (Martin Thomson) There are two places.  I started from the minutes.
[21:05:48] <zulipbot> (David Schinazi) We're getting crackling sounds from you mnot, from memory mute/unmute fixes it
[21:06:32] <zulipbot> (Martin Thomson) Have you tried turning it off and on again.
[21:06:46] <zulipbot> (Lucas Pardue) its just the oz gov tapping in
[21:06:59] <zulipbot> (Daniel Stenberg) fixed
[21:06:59] <zulipbot> (Martin Thomson) better
[21:07:16] <zulipbot> (Martin Thomson) That is Mark Nottingham's screen.
[21:07:44] <zulipbot> (Lucas Pardue) oz gov gave permission 😂
[21:07:57] <zulipbot> (Martin Thomson) Perhaps you can give the presenter the ball.
[21:08:14] <zulipbot> (Martin Thomson) Oh, you can't because you didn't upload them.
[21:08:27] <zulipbot> (Justin Richer) fullscreen the slides please?
[21:11:42] <zulipbot> (Mark Nottingham) Justin: click 'expand video'  (arrow icon next to the bitrate at the top left)
[21:16:25] <zulipbot> (Martin Thomson) with 1xx, this round trip is in parallel to the upload
[21:16:38] <zulipbot> (Julian Reschke) Why can't the initial request starting to stream the payload as well?
[21:16:51] <zulipbot> (Martin Thomson) @Julian: my point exactly
[21:17:14] <zulipbot> (Mike Bishop) Right, the token can be used if the client needs to resume that particular upload.
[21:17:36] <zulipbot> (Tommy Jensen) My read of the doc was that the initial req, the create, was also attempting to upload just in case the server doesn't support it, so I'm with everyone else (the "extra" RTT is nbd)
[21:17:49] <zulipbot> (Julian Reschke) yep, it is only needed if the initial request fails/is aborted
[21:18:14] <zulipbot> (Roy Fielding) The problem with the identifier in the header is that scalable systems partition on the request line, not on the content of the header fields. Likewise, this notion of "the server" being a single process on a single machine that the client reliably talks to after the first request fails is problematic.
[21:20:09] <zulipbot> (Martin Thomson) mnot goes straight for the porque no los dos?
[21:20:32] <zulipbot> (David Schinazi) He ran out of coins to flip
[21:20:48] <zulipbot> (Austin Wright) I think there are multiple use cases that may need multiple different (or modular) solutions. A client that needs to resume a POST request isn't exactly the same thing as a client that is appending to a file (like an audio file) in real time.
[21:23:00] <zulipbot> (Mark Nottingham) fair point mt
[21:24:08] <zulipbot> (Chris Lemmons) Is it important enough to resume small files? Is it worth building that infrastructure?
[21:24:21] <zulipbot> (Julian Reschke) if the image is small, why do you need resume in the first place?
[21:24:21] <zulipbot> (Chris Lemmons) Yeah, what he said. :)
[21:24:34] <zulipbot> (Tommy Jensen) If the server sends back an ID the client can use on subsequent requests, where is the extra RTT? Basically, the create can be ID-less until the server decides it needs one
[21:24:47] <zulipbot> (Tommy Jensen) unless* the server
[21:26:13] <zulipbot> (Guoye Zhang) We have a desire to support it in the HTTP client library itself, transparently upgrading all uploads into resumable uploads. We hope that it adds no overhead and requires no opting-in so we can do it for all uploads.
[21:27:16] <zulipbot> (Martin Thomson) that would be nice, though I believe that you would need to make some changes in Fetch to define how that works
[21:27:29] <zulipbot> (Mark Nottingham) If it's not completely transparent, a link relation could be interesting
[21:28:17] <zulipbot> (Martin Thomson) are you assuming server-defined upload targets @mnot?
[21:29:22] <zulipbot> (Mark Nottingham) y - including using a template
[21:34:58] <zulipbot> (Martin Thomson) Anne is great, so you should have no real problem
[21:36:14] <zulipbot> (Tommy Jensen) It isn't impossible, but I'm not sure why 104 is worth the effort if some of the other alternatives listed in the spec will suffice (even the presence of the Upload-Offset header on the creation response serves to inform the client resumable uploads are supported, no?)
[21:36:27] <zulipbot> (Jonathan Flat) On top of what Guoye says, it might be hard for a single client API to decide where the cutoff would be for small vs large files since this could depend on internet speed. Resuming a "small" file could be useful for those on slower internets, and being able to automatically start a resumable upload regardless of file size is nice
[21:37:22] <zulipbot> (Chris Lemmons) Well, it's a lot less important to decide what constitutes a "small" file if you're not paying a round-trip cost.
[21:38:59] <zulipbot> (Austin Wright) Comment: Could this overlap with Idempotency-Key somewhat (at the HTTP APIs WG)? That is, if your "idempotent" POST request is interrupted, you could make a RESUME request with the same URI and Idempotency-Key fields. And the server could also use 1xx to assign the request an Idempotency-Key, for clients that choose not to send one for whatever reason, or to confirm that the server will honor the Idempotency-Key for resumption.
[21:39:31] <zulipbot> (Julian Reschke) would be good to collect information about 1xx support in client libraries
[21:39:44] <zulipbot> (Julian Reschke) (on the wiki)
[21:40:09] <zulipbot> (Julian Reschke) also for 103...
[21:40:22] <zulipbot> (Lucas Pardue) and servers (+ frameworks)
[21:40:35] <zulipbot> (Julian Reschke) indeed
[21:40:49] <zulipbot> (Martin Thomson) 103 is getting better support in browsers still
[21:41:05] <zulipbot> (Marius Kleidl) We have started collecting information about support for 1XX in
[21:41:32] <zulipbot> (Marius Kleidl) Of course, it is not complete and not in a very accessible way yet.
[21:42:16] <zulipbot> (Marius Kleidl) If there are additional resources, please let us know
[21:45:08] <zulipbot> (Christopher Wood) I don't think secdir qualifies as a proper security analysis of this document.
[21:50:13] <zulipbot> (Christopher Wood) Happy to engage on that meta discussion, too.
[21:50:36] <zulipbot> (Lucas Pardue) maybe , generally, the early secdir review could advise on the level of formal analysis that might be needed
[21:50:49] <zulipbot> (Christopher Wood) ^^ is a good idea
[21:55:01] <zulipbot> (Daniel Veditz) cookies, nom nom nom
[21:55:59] <zulipbot> (Martin Thomson) I love the fact that the title of this window is what appears to be a UUID
[21:57:53] <zulipbot> (Chris Lemmons) It is a very unique meeting.
[21:58:11] <zulipbot> (Martin Thomson) is it? can you prove that?
[21:59:57] <zulipbot> (Daniel Veditz) sorry, audio problems
[22:00:14] <zulipbot> (Chris Lemmons) That raises existential questions outside the charter of this WG. :D
[22:00:31] <zulipbot> (Daniel Veditz) was the redirect breakage in all samesite cases, or mostly in the "lax by default" case?
[22:02:23] <zulipbot> (Daniel Veditz) fwiw mozilla is considering NOT implementing the "lax by default" part of the spec because of breakage and because partitioning proposals kind of mitigate the issue anyway
[22:02:52] <zulipbot> (Daniel Veditz) (not shipping, I should say -- we've implemented it)
[22:03:05] <zulipbot> (Daniel Veditz) will do
[22:03:06] <zulipbot> (Johann Hofmann) Partitioning doesn't mitigate it to be pedantic :)
[22:03:41] <zulipbot> (Martin Thomson) the problem there is that the bustage problem is pretty significant
[22:04:17] <zulipbot> (Johann Hofmann) Yeah there's already quite a lot of discussion on the GitHub threat, I made a suggestion recently and I think Freddy was also going to look into that
[22:04:30] <zulipbot> (Daniel Veditz) ... and if you fix the bustage by not enforcing the redirects then you've reopened the CSRF potential the feature was designed to solve
[22:04:30] <zulipbot> (Johann Hofmann) (who's not in this meeting, wisely given timezones)
[22:04:43] <zulipbot> (David Schinazi) The crackling is starting up again, time for another mute/unmute Mark
[22:04:43] <zulipbot> (Julian Reschke) 1am in a hotel room on vacation...
[22:05:06] <zulipbot> (Mike Bishop) @mnot, your mic static is back.
[22:05:52] <zulipbot> (David Schinazi) much better
[22:06:05] <zulipbot> (Mike Bishop) 👍
[22:06:18] <zulipbot> (Johann Hofmann) I see! I suppose the question is how do we move forward then? If browsers won't ship the arguably insecure version then shouldn't the spec document that?
[22:06:33] <zulipbot> (Johann Hofmann) But yeah we could continue on GH for better visibility :)
[22:06:52] <zulipbot> (Daniel Veditz) agreed -- back to GH, and on to other topics here
[22:07:09] <zulipbot> (Steven Bingler) 👍
[22:07:22] <zulipbot> (Martin Thomson) Brian: you are cutting out a little
[22:07:22] <zulipbot> (Johann Hofmann) Thanks Dan! 👍
[22:09:21] <zulipbot> (Martin Thomson) Yes, I'm backing you up Brian.  This isn't worth fixing, though it might be worth explaining.
[22:10:35] <zulipbot> (Mike Bishop) +1.  The client successfully presented a certificate, and the authenticated identity doesn't give it access to the resource.
[22:13:56] <zulipbot> (Martin Thomson)
[22:14:13] <zulipbot> (Martin Thomson) It's one sentence.
[22:17:31] <zulipbot> (Mike Bishop) Right; IIRC, the client can assume the proxy has certain certificates needed to build the chain.
[22:22:28] <zulipbot> (Martin Thomson) Yeah, I can imagine cases where the proxy has an intermediate certificate and the origin server doesn't
[22:23:24] <zulipbot> (Martin Thomson) what I'm suggesting avoids answering some of those questions, I think
[22:24:51] <zulipbot> (David Schinazi) Lucas did someone beat you up using your microphone?
[22:25:52] <zulipbot> (Martin Thomson) it has been getting worse over time
[22:26:05] <zulipbot> (Mike Bishop) Akamai does as well. The trouble is getting that header replaced with the "new" one, particularly if you can't phase out the old one.
[22:26:18] <zulipbot> (Lucas Pardue) yep
[22:28:25] <zulipbot> (Martin Thomson) we have a plan to meet to discuss a plan
[22:32:33] <zulipbot> (Lucas Pardue) can the WG grant honory titles like "keeper of the books"?
[22:33:16] <zulipbot> (Lucas Pardue) see
[22:33:35] <zulipbot> (Justin Richer) -1 to removing the ABNF
[22:33:48] <zulipbot> (Justin Richer) (if we go that far)
[22:34:11] <zulipbot> (Mike Bishop) I'm not inclined to re-open the draft. Update it if you want a clear linkage between them.
[22:35:02] <zulipbot> (Tommy Pauly) +1 to keeping the structured fields spec as one thing. Updating is better than spinning off a new draft.
[22:36:56] <zulipbot> (Mike Bishop) If we write it later, there may be other extensions that also get rolled up.
[22:37:14] <zulipbot> (Martin Thomson) +1 to keeping scope in check
[22:37:27] <zulipbot> (Justin Richer) +1 to tight scope however this goes
[22:37:40] <zulipbot> (Martin Thomson) We did that with h2bis and it took a year, but that had some real issues.  This can be better.
[22:37:41] <zulipbot> (Tommy Pauly) Sounds good
[22:37:53] <zulipbot> (Justin Richer) 👍
[22:38:06] <zulipbot> (Martin Thomson) "it's alive!"
[22:38:07] <zulipbot> (David Schinazi) a LIVING specification, that's HERESY Mark
[22:38:20] <zulipbot> (Justin Richer) "HTTP, whatever that means today"
[22:38:20] <zulipbot> (David Schinazi) "Le HTTP du jour"
[22:38:37] <zulipbot> (Daniel Stenberg) \o