IETF
httpbis
httpbis@jabber.ietf.org
Friday, November 11, 2022< ^ >
Martin Thomson has set the subject to: https://github.com/httpwg/wg-materials/blob/gh-pages/interim-20-05/agenda.md
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-httpbis-01-httpbis?useMonospaceFont=true
Room Configuration
Room Occupants

GMT+0
[09:19:27] <zulipbot> (Julian Reschke) Moin, Martin.
[09:30:50] <zulipbot> (Eric Orth) Last morning waking up this early.  Then begins the game of seeing how many days it takes me to recover to normalcy.
[09:31:32] <zulipbot> (Julian Reschke) camera pointing at Mark needs a slight adjustment
[09:33:03] <zulipbot> (Francesca Palombini) good morning
[09:34:19] <zulipbot> (Julian Reschke) Francesca - thanks again for taking care of the errata
[09:35:10] <zulipbot> (Alan Frindell) Your floating head game is good Tommy but Mark still wins
[09:35:23] <zulipbot> (Francesca Palombini) of course! we have a huge backlog in ART unfortunately and I am trying to get that fixed :) thank you and others for making my work easier by discussing them in the mailing list :)
[09:37:01] <zulipbot> (Julian Reschke) at least for HTTPbis, my goal is to have everything evaluated, and anything that's not rejected will have a github issue for tracking
[09:37:35] <zulipbot> (Julian Reschke) yep
[09:37:48] <zulipbot> (Tommy Pauly) Yes
[09:37:48] <zulipbot> (Francesca Palombini) that's great. And if I miss any of them do ping me
[09:38:45] <zulipbot> (Jonathan Flat) Example implementation: https://github.com/tus/draft-example
[09:39:07] <zulipbot> (Lucas Pardue) if there's agenda time spare at the end, I can use 5 minutes :)
[09:42:09] <zulipbot> (Kazuho Oku) Is it now server-generated *URL* vs. client-generated token?
[09:42:22] <zulipbot> (Kazuho Oku) IIRC it was about tokens
[09:45:12] <zulipbot> (Tommy Jensen) Strongly in favor of server-issued, mildly in favor of server-issued-URL over server-issued-token
[09:55:22] <zulipbot> (Luke Curley) regarding the HLS/DASH playlist discussion, the chunk size is a contentions topic
[09:56:04] <zulipbot> (Ted Hardie) I dropped out of the queue, so people can go on into this discussion, but I think there is a larger discussion to be had here.  With a manifest-based system (like DASH), then I agree with Martin.  But that doesn't work with other approaches as some types of pub/sub for realtime might work differently (as they might not have sub resources).  I would be happy to have that conversation here, but it might also make sense to post this draft to MoQ, and to see if folks there have similar thoughts.
[09:56:18] <zulipbot> (Kirill Pugin) it's not just playlist - client can be downloading media segment that is still being produced by backend
[09:56:18] <zulipbot> (Luke Curley) ideally we can upload a frame at a time, which means a playlist update every 16ms, and that starts to get far too frequent to constantly push manifest updates
[09:57:30] <zulipbot> (Kazuho Oku) From server's viewpoint, I'm not sure how we can prohibit parallel upload (or want to).
[09:57:53] <zulipbot> (Kazuho Oku) An old TCP connection might be still active when a new one is established from the client.
[09:58:27] <zulipbot> (Lucas Pardue) regarding parallel uploads: i've heard there are benefits beyond bandwidth aggregation on the client -> server hop, for instance, parllelism better matches some server-side storage architectures
[10:04:01] <zulipbot> (Benjamin Schwartz) Parallel download is often viewed as antisocial due to congestion control unfairness, so I would steer clear of documenting parallel upload for now.
[10:06:48] <zulipbot> (Martin Thomson) Definitely not "Expect"
[10:07:06] <zulipbot> (Julian Reschke) prefer prefer
[10:08:46] <zulipbot> (Martin Thomson) I'm not sure about this one.  We can certainly add this signal to all requests that have a non-trivial-sized body (or even any body), but it might get a little noisy if we added it to all requests.
[10:09:04] <zulipbot> (Martin Thomson) I do prefer prefer as a signal, but it might be worth trying to make the tag smaller.
[10:09:17] <zulipbot> (Martin Thomson) Prefer: resumable
[10:11:04] <zulipbot> (Jonathan Hoyland) If the client supports it, but only some of the server's backend services do, do you need to allow the server to indicate?
[10:12:59] <zulipbot> (Roberto Polli) Parallel can be useful in different context.
[10:13:35] <zulipbot> (Lucas Pardue) +1 Jonathan Flat. It becomes a function of content size, path characteristics and flow control (esp. H2 or H3)
[10:13:48] <zulipbot> (Kirill Pugin) what if client doesn't know size of the upload?
[10:14:01] <zulipbot> (Lucas Pardue) that too
[10:14:01] <zulipbot> (Martin Thomson) Expect: 100-continue allows the client to ask permission based on upload size, though that depends on knowing the size - we don't have way to say "this might be big".
[10:14:14] <zulipbot> (Jonathan Hoyland) What is largest small file? What is the smallest large file? Do these two values overlap?
[10:14:27] <zulipbot> (Martin Thomson) No conflict.
[10:14:40] <zulipbot> (Martin Thomson) I'd be OK with 100 responses having the URL attached to them
[10:15:12] <zulipbot> (Martin Thomson) Maybe don't send the 104 before the 100
[10:16:18] <zulipbot> (Martin Thomson) The HEAD thing isn't a problem - people like caching HEAD, but as long as you don't engage heuristic caching, it should be OK if the resource changes constantly
[10:17:45] <zulipbot> (Martin Thomson) Digest field authors, I summon you!
[10:18:35] <zulipbot> (Lucas Pardue) yes, use digests https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html
[10:18:54] <zulipbot> (Kazuho Oku) Assuming that we have an upload URL (w. token) which is different from the target resource, how does the final response get sent?
[10:19:07] <zulipbot> (Martin Thomson) we have a way to use Digest for conveying the current state of a selected representation
[10:19:20] <zulipbot> (Roberto Polli) +1 Digest flavors can do it
[10:19:33] <zulipbot> (Martin Thomson) @**Kazuho Oku** oh, yeah, that's a very interesting question
[10:19:33] <zulipbot> (Martin Thomson) Open an issue on that one?
[10:19:46] <zulipbot> (Kazuho Oku) Will do.
[10:19:46] <zulipbot> (Martin Thomson) Thanks.
[10:19:59] <zulipbot> (Lucas Pardue) 😍
[10:25:23] <zulipbot> (Julian Reschke) +1 to adding a mode to the core parser
[10:30:09] <zulipbot> (Kazuho Oku) filed https://github.com/httpwg/http-extensions/issues/2312
[10:31:09] <zulipbot> (Ted Hardie) I kind of wonder if there is a way to do something similar here with specialized idempotency key headers.  So you could get an idempotent POST or PATCH, without a distinct method.
[10:31:49] <zulipbot> (Benjamin Schwartz) Same.  Why do we need QUERY if we have Idempotency-Key?  Would we even need any changes to the Idempotency-Key draft?
[10:35:36] <zulipbot> (Roberto Polli) QUERY allows discriminating idempotent requests before examining fields and payloads @ben
[10:35:55] <zulipbot> (Benjamin Schwartz) @**Roberto Polli** True.  Why is that valuable?
[10:36:28] <zulipbot> (Roberto Polli) An API Gateway can redirect idempotent requests to specific parts of an infrastructure
[10:36:29] <zulipbot> (Jonathan Hoyland) Woo! Hi Sudheesh 👋
[10:36:41] <zulipbot> (Benjamin Schwartz) Surely an API gateway would at least parse the headers before redirecting requests.
[10:38:53] <zulipbot> (Roberto Polli) not sure every gateway needs to. Moreover a gw could just 405 early if it only wants to receive idempotent reqs
[10:39:11] <zulipbot> (Martin Thomson) I feel obligated to represent our branding strategy people and say that that isn't the Firefox logo
[10:39:37] <zulipbot> (Benjamin Schwartz) Again, would the gateway really respond to a request before parsing the headers?  That seems very aggressive.
[10:40:16] <zulipbot> (Sam Hurst) Either someone has some very heavy breathing, or someone's fallen asleep with their mic on, at least that's what it sounds like
[10:40:42] <zulipbot> (Ted Hardie) That this is looking at this as "no more than 6 ASes" makes me nostalgic for very different days when more than 1 would have been surprising.
[10:40:55] <zulipbot> (Jonathan Hoyland) I was thinking it was a humidifier
[10:40:56] <zulipbot> (Valentin Goșu) Note that Firefox's coalescing strategy might be too aggressive for some [Bug 1420777 - Http/2 connection reuse to non-origin server for new hostname on DNS overlap](https://bugzilla.mozilla.org/show_bug.cgi?id=1420777)
[10:43:02] <zulipbot> (Martin Thomson) @**Valentin Goșu** (╯°□°）╯︵ ┻━┻
[10:44:41] <zulipbot> (Martin Thomson) This is totally the model that was originally envisaged for ORIGIN, but we have had long arguments about the significance of the role that DNS plays.
[10:45:20] <zulipbot> (Jonathan Hoyland) We opened a PR against Go that adds ORIGIN Frame support. They rejected it because H3 ORIGIN isn't yet an RFC. (No, Go doesn't support H3.)
[10:46:25] <zulipbot> (Martin Thomson) Does this modeling consider the effect of the congestion control window on the transfer of subresources?  It doesn't look like it does from the figure here.
[10:46:52] <zulipbot> (Martin Thomson) Or is that the point of these experiments
[10:48:10] <zulipbot> (Martin Thomson) OK, thanks
[10:50:52] <zulipbot> (Martin Thomson) It is quite possible that we re-run certificate validation on the coalesced origin in the browser.  I don't know for sure.  @**Valentin Goșu** do you happen to know?
[10:51:55] <zulipbot> (Ted Hardie) So, it would be interesting to see what the exact SAN modifications were; is that in a different version of this presentation?
[10:51:56] <zulipbot> (Lucas Pardue) results affected by prioritization too
[10:52:09] <zulipbot> (Kershaw Chang) @Martin Thomson, yes we do.
[10:52:22] <zulipbot> (Martin Thomson) Thanks for confirming @**Kershaw Chang**
[10:52:48] <zulipbot> (Martin Thomson) @**Ted Hardie** there is a paper that contains a bunch more detail
[10:53:14] <zulipbot> (Jonathan Hoyland) @**Ted Hardie**  So the full paper is here https://dl.acm.org/doi/pdf/10.1145/3517745.3561453
The only change to the SAN is to add either cdnjs.cloudflare.com or drand.cloudflare.com (used as a control)
[10:54:05] <zulipbot> (Ted Hardie) @jonathan Hoyland  thanks.  I must have misheard him, because I thought he said it required adding 10 names to the SAN.  Thanks for the correction.
[10:55:42] <zulipbot> (Jonathan Hoyland) @**Ted Hardie** The paper covers a series of measurements and experiments, the 10 SANs bit was relevant to Section 4 in the paper, this relates to Section 5
[10:55:55] <zulipbot> (Lucas Pardue) coalescing connections raises interesting challenges for stream concurrency limits
[10:55:56] <zulipbot> (Jonathan Hoyland) We probably should have made that clearer in the slides, sorry
[10:56:22] <zulipbot> (Martin Thomson) @**Lucas Pardue** but you get to do cross-origin prioritization, which seems like a real gain
[10:57:04] <zulipbot> (Lucas Pardue) I agree! just no naive silver bullets here - we need better tooling to understand the actual behaviours
[10:57:17] <zulipbot> (Benjamin Schwartz) There's also a fun game theory problem, if multiple connections gets you a larger fraction of the bottleneck link.
[10:57:43] <zulipbot> (Lucas Pardue) also, what Ben said :D
[10:58:26] <zulipbot> (Alan Frindell) We've seen wins from coalescing images and videos which were previously served from different VIPs and being able to prioritize them
[10:58:52] <zulipbot> (Jonathan Hoyland) @**Benjamin Schwartz** We discuss that in the paper, that's one of the reasons why we think we didn't see an increase in performance.
[10:59:09] <zulipbot> (Jonathan Hoyland) (And I suspect performance on congested links would be pretty painful.)
[10:59:22] <zulipbot> (Benjamin Schwartz) See also parallel uploads!
[11:00:58] <zulipbot> (Lucas Pardue) throwing this out there: H2 spec encourages a single connection. Maybe for highly coalesced connections, we might encourage some level of connection pooling
[11:09:47] <zulipbot> (Lucas Pardue) +1 to not httpapi
[11:10:00] <zulipbot> (Jonathan Hoyland) You don't want to send it to dispatch?
[11:10:13] <zulipbot> (Alexey Melnikov) Weak preference for doing this in HTTPBIS
[11:11:06] <zulipbot> (Ted Hardie) Do I understand correctly that one motivation for request proxying is happy eyeballs?
[11:11:06] <zulipbot> (Kazuho Oku) Re Modern HTTP Request Proxy, I wonder how we can disambiguate from existing URLs (because there is no :protocol pseudo header).
[11:11:19] <zulipbot> (Kazuho Oku) Maybe .well-known will solve that but
[11:11:32] <zulipbot> (Francesca Palombini) dispatch is not a mandatory step if people can come to a consensus otherwise... but it is an option
[11:13:01] <zulipbot> (Martin Thomson) There is nothing intrinsically wrong with sending a request for https://example.com/foo to proxy.example
[11:13:35] <zulipbot> (Martin Thomson) That is, if you don't mind proxy.example seeing your request and being able to modify it or any response.
[11:13:48] <zulipbot> (Jonathan Hoyland) Assuming all the SANs overlap? Or just in general?
[11:14:01] <zulipbot> (Jorge Silva) @**Ted Hardie** ,  re: happyeyeballs that's right. Forward Proxies can only do happyeyeballs today if you explicitly provide a hostname. If you have an IPv6 and IPv4 addresses you'd like to race , there's really no standard way of specifying that.
[11:14:14] <zulipbot> (Lucas Pardue) ngProxies
[11:14:27] <zulipbot> (Tommy Jensen) +1 to needing motivation to dust off proxy code. Use cases would be good.
[11:14:40] <zulipbot> (David Schinazi) @Ted You can do happy eyeballs with regular CONNECT if you pass in a hostname
[11:19:47] <zulipbot> (Alexey Melnikov) SASL related developments are happening in the KITTEN WG
[11:21:06] <zulipbot> (Jonathan Hoyland) Yeah, but they're very highly resistant to channel bindings / doing things properly, so I don't think that's a stream of work we want to follow.
[11:24:36] <zulipbot> (Alexey Melnikov) Because something is not perfect let's not do anything Jonathan?
[11:27:45] <zulipbot> (Jonathan Hoyland) Much much better to not build something with known bad security. If it's broken by design it's just going to be an excruciating pain in the neck and source of security issues over the next decade, and we'll eventually burn lots of cycles on a die-die-die draft.
[11:28:11] <zulipbot> (Jonathan Hoyland) It's not like we don't know how to do things properly.
[11:32:10] <zulipbot> (Francesca Palombini) thank you!
[11:32:10] <zulipbot> (Roberto Polli) :wave Thank you!
[16:55:54] <zulipbot> (Henry Story) Today I found out at SAAG that mastodon is using a much older version of http signatures.
I dug a bit more into the use of the older version of HTTP Signatures in Mastodon and put it together in this thread https://mathstodon.xyz/@bblfish/109326189343436621
[16:56:00] seabass leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!