Why so silent?
", "time": "2023-03-31T00:31:18Z"}, {"author": "Jonathan Lennox", "text": "Can someone from the room confirm we can hear you?
", "time": "2023-03-31T00:31:42Z"}, {"author": "Jonathan Lennox", "text": "(I.e. talk into a mic)
", "time": "2023-03-31T00:31:49Z"}, {"author": "Lorenzo Miniero", "text": "Mics are turned off I think
", "time": "2023-03-31T00:32:03Z"}, {"author": "Jonathan Lennox", "text": "There we go!
", "time": "2023-03-31T00:32:14Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "I can hear at last
", "time": "2023-03-31T00:32:18Z"}, {"author": "Christian Huitema", "text": "I still do not hear anything.
", "time": "2023-03-31T00:35:41Z"}, {"author": "Julian Reschke", "text": "Works for me.
", "time": "2023-03-31T00:35:56Z"}, {"author": "Ian Williams", "text": "Nothing from here, either
", "time": "2023-03-31T00:36:21Z"}, {"author": "Momoka Yamamoto", "text": "@Marius Kleidl
\nHi Marius!!
Still showing \"a new deck is being shared\", with no deck.
", "time": "2023-03-31T00:36:47Z"}, {"author": "Julian Reschke", "text": "that is true
", "time": "2023-03-31T00:37:03Z"}, {"author": "Ted Hardie", "text": "If there is no deck, perhaps the dialog needs to be dismissed?
", "time": "2023-03-31T00:37:05Z"}, {"author": "Jonathan Lennox", "text": "I see a deck
", "time": "2023-03-31T00:37:35Z"}, {"author": "Kenneth Murchison", "text": "I refreshed and now have the deck
", "time": "2023-03-31T00:37:39Z"}, {"author": "Julian Reschke", "text": "...field...
", "time": "2023-03-31T00:39:08Z"}, {"author": "Tommy Pauly", "text": "Indeed, field
", "time": "2023-03-31T00:41:29Z"}, {"author": "Pete Resnick", "text": "Does http have the same concept as SMTP with 4xx meaning \"nope, but you can try again\" and 5xx meaning \"don't bother trying again\"?
", "time": "2023-03-31T00:41:34Z"}, {"author": "Martin Thomson", "text": "Upload-Complete: ?1 on a request is a little bizarre. It implies a statement about the status of the upload process, but it is a statement that needs to be made before doing anything.
(I knew it was worthwhile getting up at 2am)
", "time": "2023-03-31T00:41:56Z"}, {"author": "Pete Resnick", "text": "+1 @Martin Thomson Seems like if the upload is not complete, the client should say, \"This isn't all of it\". If the upload is complete, the client can say nothing at all.
", "time": "2023-03-31T00:44:45Z"}, {"author": "Martin Thomson", "text": "Upload-Partial ?
More-To-Come
", "time": "2023-03-31T00:45:35Z"}, {"author": "Kenneth Murchison", "text": "Wait-For-It
", "time": "2023-03-31T00:46:58Z"}, {"author": "Ted Hardie", "text": "Strongly-worded-letter-to-follow
", "time": "2023-03-31T00:47:11Z"}, {"author": "Marius Kleidl", "text": "@Pete: Correct, that is the intention of the header
", "time": "2023-03-31T00:47:11Z"}, {"author": "Marius Kleidl", "text": "Do you think that the naming of the header is just poor or if the entire concept is not well suited?
", "time": "2023-03-31T00:47:49Z"}, {"author": "Martin Thomson", "text": "Can someone summarize the issue?
", "time": "2023-03-31T00:47:51Z"}, {"author": "Mark Nottingham", "text": "https://github.com/httpwg/http-extensions/issues/2343
", "time": "2023-03-31T00:49:27Z"}, {"author": "David Benjamin", "text": "Thanks! Was having a hard time finding it digging around GitHub.
", "time": "2023-03-31T00:49:44Z"}, {"author": "Jonathan Lennox", "text": "Are there any new header fields people are proposing that would want unicode text in them?
", "time": "2023-03-31T00:55:28Z"}, {"author": "Adam Rice", "text": "Plz no top bit set
", "time": "2023-03-31T00:56:04Z"}, {"author": "Pete Resnick", "text": "Martin's choice 3 (new type) seems like a good choice, but \"just shove Unicode in there\" is not actually a meaningful phrase. I presume you mean \"UTF-8 encoded Unicode\".
", "time": "2023-03-31T00:56:13Z"}, {"author": "David Benjamin", "text": "Location in browserrs doesn't take arbitrary unicode per se. It takes arbitrary bytes and %-encodes them without any understanding of what the bytes are.
", "time": "2023-03-31T00:56:35Z"}, {"author": "Julian Reschke", "text": "There wasn an HTTPAPI spec that had one in SF with a new encoding mechanism, but that header field was dropped from the spec
", "time": "2023-03-31T00:56:47Z"}, {"author": "David Benjamin", "text": "(We definitely did not accidentally break Wikipedia by getting this \"wrong\" many years back...)
", "time": "2023-03-31T00:57:11Z"}, {"author": "Martin Thomson", "text": "@Pete Resnick Yep. Me being fast and loose with words, because spelling it out correctly takes too long.
", "time": "2023-03-31T00:58:56Z"}, {"author": "David Benjamin", "text": "(Location header mess: https://github.com/whatwg/fetch/issues/883 )
", "time": "2023-03-31T00:59:20Z"}, {"author": "Martin Thomson", "text": "UTF-8 is the only sensible option
", "time": "2023-03-31T00:59:25Z"}, {"author": "Pete Resnick", "text": "I think you're going to have to bite the bullet at some point. Might as well do it while the document is open. I suspect it won't be as hard as some people think.
", "time": "2023-03-31T01:00:56Z"}, {"author": "Martin Thomson", "text": "@Mark Nottingham pointed out that we'd need to update RFC 9110. Yes, but we should not open it. Rather we should just update it. obs-text is already permitted, which would allow us to do UTF-8 (I think).
", "time": "2023-03-31T01:00:57Z"}, {"author": "Benjamin Schwartz", "text": "Percent-encoding seems much more attractive to me. I fear what happens when arbitrary UTF-8 lands in the long tail of unmaintained HTTP parsers, log processing systems, etc.
", "time": "2023-03-31T01:00:57Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "How many MUAs supports RFC 6532 \"Internationalized Email Headers\" already?
", "time": "2023-03-31T01:01:26Z"}, {"author": "Jonathan Lennox", "text": "I'm sure BOMs in logs will be able to cause all sorts of exciting chaos.
", "time": "2023-03-31T01:01:32Z"}, {"author": "Martin D\u00fcrst", "text": "@Martin Thomson do you mean in the string type we have now, or as a new, separate type?
", "time": "2023-03-31T01:01:33Z"}, {"author": "Benjamin Schwartz", "text": "At best, I expect some very exciting mojibake for people trying to read the logs.
", "time": "2023-03-31T01:01:41Z"}, {"author": "Julian Reschke", "text": "+1
", "time": "2023-03-31T01:01:47Z"}, {"author": "Adam Rice", "text": "+1 to percent encoding
", "time": "2023-03-31T01:02:14Z"}, {"author": "Kazuho Oku", "text": "The only comment I have is that we'd prefer continuing sf-string defined as US-ASCII, unless there's a reason to store purely textual data.
\nAs much as Structured Fields have improved the situation, there are HTTP extensions that require parsing sf-string; parsing utf-8 in a caseless manner is much much harder than US-ASCII
@Martin D\u00fcrst We could use to \"UTF-8\", which would be in the existing type, but that has a host of compatibility problems. The third option I had was to have some other type, perhaps u\"UTF-8\" for strings that contain non-ASCII bytes/codepoints.
", "time": "2023-03-31T01:02:50Z"}, {"author": "Pete Resnick", "text": "@Benjamin Schwartz For better/worse, I'd bet \u00a55 that in most cases unmaintained HTTP parsers will probably just work with arbitrary UTF-8.
", "time": "2023-03-31T01:02:59Z"}, {"author": "Jonathan Lennox", "text": "But then there are probably already plenty of servers that log verbatim what's in the requests, which means you can send them BOMs and other exciting things already.
", "time": "2023-03-31T01:03:10Z"}, {"author": "Jonathan Lennox", "text": "(Probably terminal escape codes, too, for that matter.)
", "time": "2023-03-31T01:03:23Z"}, {"author": "Mark Nottingham", "text": "https://github.com/httpwg/http-extensions/issues/2280
", "time": "2023-03-31T01:03:41Z"}, {"author": "Martin Thomson", "text": "@Jonathan Lennox LFLFLFLFLFLFLFLF
", "time": "2023-03-31T01:03:51Z"}, {"author": "Kazuho Oku", "text": "I think the question is if there would be ambiguity between different parsers, and if that'd lead to security issues (because endpoints disagree what things mean)
", "time": "2023-03-31T01:04:20Z"}, {"author": "Martin D\u00fcrst", "text": "BOMs shouldn't and don't in general appear in text fields. If they ever appear, they are essentially meaningless nonvisible spaces.
", "time": "2023-03-31T01:04:44Z"}, {"author": "Martin Thomson", "text": "@Kazuho Oku Yes, we're opening a can, which might contain worms (or a wormhole). But it's worth it.
", "time": "2023-03-31T01:04:54Z"}, {"author": "Jonathan Lennox", "text": "Sorry, I meant LTR/RTL codes, not BOMs.
", "time": "2023-03-31T01:05:30Z"}, {"author": "Jonathan Lennox", "text": "Whatever the term is for that.
", "time": "2023-03-31T01:05:37Z"}, {"author": "Benjamin Schwartz", "text": "Martin Thomson said:
\n\n\nKazuho Oku Yes, we're opening a can, which might contain worms (or a wormhole). But it's worth it.
\n
Percent encoding has worked fine in URIs. Why is UTF-8 worth it in headers?
", "time": "2023-03-31T01:05:58Z"}, {"author": "Kazuho Oku", "text": "I'm fine with having a utf-8 string type in Structured Headers.
", "time": "2023-03-31T01:06:05Z"}, {"author": "Jonathan Lennox", "text": "With the attacks based on putting direction markers in source code, so it's unclear what's inside or outside the comments.
", "time": "2023-03-31T01:06:06Z"}, {"author": "Adam Rice", "text": "I think top-bit-set characters should be defined as \"ill-defined legacy stuff\" and avoided in new standards.
", "time": "2023-03-31T01:06:27Z"}, {"author": "Julian Reschke", "text": "I still don't get why we need scheme specific mappings
", "time": "2023-03-31T01:06:29Z"}, {"author": "Martin D\u00fcrst", "text": "@Kazuho Oku non-ASCII should not be used for stuff that's relevant to the protocol. Also, UTF-8 is very easily distinguishable from virtually all other encodings.
", "time": "2023-03-31T01:06:34Z"}, {"author": "Martin Thomson", "text": "Percent encoding is a relic. It works, but it has pretty poor efficiency properties.
", "time": "2023-03-31T01:07:02Z"}, {"author": "Martin Thomson", "text": "It is also pretty user-hostile. It puts another layer between you and the stack.
", "time": "2023-03-31T01:07:28Z"}, {"author": "Kazuho Oku", "text": "@Martin D\u00fcrst right. So the question is how we should limit use of non-ASCII chars for the information stacks have to parse and understand.
", "time": "2023-03-31T01:08:01Z"}, {"author": "Martin Thomson", "text": "A discrete SF type works for that, doesn't it?
", "time": "2023-03-31T01:08:31Z"}, {"author": "Benjamin Schwartz", "text": "Percent-encoding seems more user-friendly to me. I can confidently copy-paste percent-encoded unicode, but I have no idea what deep magic is happening when I copy-paste UTF-8.
", "time": "2023-03-31T01:08:34Z"}, {"author": "Kazuho Oku", "text": "my +1 does go to discrete SF type
", "time": "2023-03-31T01:08:48Z"}, {"author": "Pete Resnick", "text": "@Benjamin Schwartz percent-encoding does cause heartburn with double/triple encoding when they are passed between processes. Mostly the right thing happens, but they're far from perfect. And I also think that people are going to let un-percent-encoded UTF-8 leak into headers anyway, so might as well make a standard way to do it.
", "time": "2023-03-31T01:09:25Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz That's a very ASCII-centric viewpoint that I don't share. Copy-paste works.
", "time": "2023-03-31T01:09:27Z"}, {"author": "Alex Chernyakhovsky", "text": "percent-encoded unicode in what encoding? IIRC percent-encoding only works on bytes, so presumably you mean %-encoded utf8?
", "time": "2023-03-31T01:09:28Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "Yeah, \"copy-paste UTF-8\" is very dangerous.
", "time": "2023-03-31T01:09:31Z"}, {"author": "Martin D\u00fcrst", "text": "@Adam Rice Many new standards use UTF-8, and are very fine with it. Many old standards added UTF-8, and are fine with it. Many standards that use charset labeling converge(d) on UTF-8, and are fine with it. UTF-8 is not legacy at all!
", "time": "2023-03-31T01:09:38Z"}, {"author": "David Benjamin", "text": "Agreed %-encoding is terrible in a vacuum, but I think the question is how mired are we in this mess. It may be the more pragmatic option, sadly. (Don't personally have a strong opinion but lean towards %-encoding to avoid having to worry about this.) On the browser at least, there'll be a layer between you and the stack anyway because the all HTTP header APIs are interpreted as their string inputs/outputs as Latin-1. (Aka the \"ByteString\" type in Web IDL.)
", "time": "2023-03-31T01:09:53Z"}, {"author": "Martin Thomson", "text": "@David Benjamin not all
", "time": "2023-03-31T01:10:25Z"}, {"author": "Kazuho Oku", "text": "(wonders if we start seeing non-ASCII names in User-Agent)
", "time": "2023-03-31T01:10:26Z"}, {"author": "Alex Chernyakhovsky", "text": "We've already seen servers giving usnon-ascii non-utf-8 headers...
", "time": "2023-03-31T01:10:53Z"}, {"author": "Martin D\u00fcrst", "text": "@Benjamin Schwartz The magic that happens with UTF-8 copy-paste is exactly the magic that should happen.
", "time": "2023-03-31T01:11:00Z"}, {"author": "David Benjamin", "text": "@Martin Thomson Hmm, I think I meant to type \"our\" instead of \"all\", although which API interprets headers as UTF-8?
", "time": "2023-03-31T01:11:19Z"}, {"author": "David Benjamin", "text": "(I'm very bad at typing and randomly swap words without noticing! :-) )
", "time": "2023-03-31T01:11:34Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "@Martin Thomson In some cases, copy-paste one Japanese character results in two characters...
", "time": "2023-03-31T01:11:46Z"}, {"author": "Kazuho Oku", "text": "User-Agent is an example of a string that meant to be just a label but in fact many people parse
", "time": "2023-03-31T01:11:48Z"}, {"author": "Martin Thomson", "text": "@David Benjamin I believe that we are required to accept UTF-8 for some fields.
", "time": "2023-03-31T01:11:52Z"}, {"author": "Martin Thomson", "text": "@Kazuho Oku I think that User-Agent will remain disgusting, but only disgusting ASCII
", "time": "2023-03-31T01:12:19Z"}, {"author": "David Benjamin", "text": "I'm fairly sure the fetch and XHR APIs both use the ByteString type, which does \"byte\" pass-through. You can't really do both UTF-8 and byte pass-through in the same API since it's ambiguous.
", "time": "2023-03-31T01:12:54Z"}, {"author": "David Benjamin", "text": "Byte pass-through = if the UTF-16 code unit > 256, error, otherwise intrepret it as a byte. Also know as Latin-1. Or \"isometric encode\" in WHATWG.
", "time": "2023-03-31T01:13:25Z"}, {"author": "Martin Thomson", "text": "@David Benjamin This is SF, in which this is unambiguous.
", "time": "2023-03-31T01:13:27Z"}, {"author": "Martin D\u00fcrst", "text": "@\u5c71\u672c\u548c\u5f66 Can you give an example of one Japanese character turning into two?
", "time": "2023-03-31T01:13:34Z"}, {"author": "David Benjamin", "text": "Right, but fetch and XHR don't know which headers are SF. An SF-aware or header-specific API would be able to handle it, of course, but such an API can handle any encoding as long as it's defined.
", "time": "2023-03-31T01:14:02Z"}, {"author": "Martin Thomson", "text": "@David Benjamin Right. But that is what we are talking about. If you know that the field is SF, you process as SF and fail if it isn't. Otherwise, you have a chain of bytes.
", "time": "2023-03-31T01:14:40Z"}, {"author": "Adam Rice", "text": "I'm not saying UTF-8 is legacy. I'm a big fan of UTF-8. I'm saying the top-bit in header values essentially acts as a flag that you're going to have a bad time, and adding more use of top-bit-set use will only make the situation worse.
", "time": "2023-03-31T01:14:54Z"}, {"author": "Martin D\u00fcrst", "text": "@David Benjamin agree. I have heard the term \"binary string\" in another session. I'd like to ban that, and make sure we have a clear distinction between binary blobs and UTF-8 strings.
", "time": "2023-03-31T01:15:31Z"}, {"author": "Alex Chernyakhovsky", "text": "@Adam Rice can you say why that's the case?
", "time": "2023-03-31T01:15:31Z"}, {"author": "Pete Resnick", "text": "@Adam Rice I think that may have been the case at one point, but I suspect it may not be true anymore. Most libraries that handle text seem to do \"the right thing\" when handed UTF-8.
", "time": "2023-03-31T01:16:23Z"}, {"author": "David Benjamin", "text": "@Martin Thomson I think we may be agreeing then. :-) I'm just saying that %-encoding vs UTF-8 bytes on the wire doesn't make any difference to SF-aware APIs because you just encode it in whatever we decided to do. SF-unaware APIs are stuck taking byte strings (be they true byte strings, or byte strings in strings' clothing like the browser regrettably does).
", "time": "2023-03-31T01:16:24Z"}, {"author": "Adam Rice", "text": "Because servers tend to emit headers in whatever encoding they happen to be configured for, and clients tend to assume it's whatever encoding they'd like it to be.
", "time": "2023-03-31T01:16:59Z"}, {"author": "\u5c71\u672c\u548c\u5f66", "text": "@Martin D\u00fcrst
\n\"\u3073\" -> \"\u3072\u309b\"
\nNote that this is old macOS's bug.
The bug does not seem to appear in the current macOS.
", "time": "2023-03-31T01:24:03Z"}, {"author": "Adam Rice", "text": "", "time": "2023-03-31T01:25:06Z"}, {"author": "Kazuho Oku", "text": "yeah \"\u3073\" -> \"\u3072\u309b\" this kind of conversion is still real for things like filesystem and it's not going to go away.
", "time": "2023-03-31T01:27:20Z"}, {"author": "Martin Thomson", "text": "@Adam Rice I'm sorry, my browser isn't able to find an element with that anchor name.
", "time": "2023-03-31T01:29:04Z"}, {"author": "Kazuho Oku", "text": "Unicode allows characters to be \"normalized\" that ends up in different representations, some applications tend to prefer particular way
", "time": "2023-03-31T01:29:49Z"}, {"author": "Pete Resnick", "text": "@Adam Rice
\n@Adam Rice paragraphs in RFCs have pilcrows that let you link to them directly without resorting to proprietary extensions
", "time": "2023-03-31T01:30:27Z"}, {"author": "Adam Rice", "text": "Sorry, https://www.rfc-editor.org/rfc/rfc9110.html#section-5.5-4
", "time": "2023-03-31T01:31:05Z"}, {"author": "Pete Resnick", "text": "I always forget that \u00b6 is called a \"pilcrow\" and always love that they have such a name whenever I am reminded of it.
", "time": "2023-03-31T01:31:51Z"}, {"author": "Erik Nygren", "text": "Tommy's suggestion makes sense --- change roll-out/roll-back are a situation where ECH may disappear.
", "time": "2023-03-31T01:32:07Z"}, {"author": "Martin D\u00fcrst", "text": "@\u5c71\u672c\u548c\u5f66 \"\u3073\" and \"\u3072\u309b\" should actually display exactly the same, because they are canonically equivalent. Not sure why that's not the case.
", "time": "2023-03-31T01:32:36Z"}, {"author": "Martin Thomson", "text": "I'm sure that people would love for clients to poll the DNS continuously, but that suggestion seems a little tough to manage.
", "time": "2023-03-31T01:32:53Z"}, {"author": "Martin Thomson", "text": "In that case, Alt-SvcB: the.origin.you.are.talking.to might be a cleaner solution.
@Adam Rice Thanks for the quote. Note that it's a SHOULD (or two), and may easily come to the conclusion that we have good reasons to override them.
", "time": "2023-03-31T01:34:08Z"}, {"author": "Martin Thomson", "text": "Yeah, this really seems like a case where we might decide to override that guidance. Though it suggests that some care is needed.
", "time": "2023-03-31T01:35:09Z"}, {"author": "Pete Resnick", "text": "https://www.rfc-editor.org/rfc/rfc2119.html#section-3
", "time": "2023-03-31T01:35:43Z"}, {"author": "Martin Thomson", "text": "FWIW, HTTP/2 and HTTP/3 are very clear about field names being bytes, not ASCII or Latin-1 or ISO 8859-1 strings.
", "time": "2023-03-31T01:35:44Z"}, {"author": "Martin D\u00fcrst", "text": "@Martin Thomson I think nobody is talking about using ron-ASCII in field names.
", "time": "2023-03-31T01:36:40Z"}, {"author": "Martin Thomson", "text": "Oops, I did what David was doing. Yes, values.
", "time": "2023-03-31T01:36:59Z"}, {"author": "Martin Thomson", "text": "But HTTP/2 and HTTP/3 also treat names as bytes.
", "time": "2023-03-31T01:37:11Z"}, {"author": "Martin D\u00fcrst", "text": "I think HTTP/2 and HTTP/3 are fine that way (as transports). We just have to make sure we use this well, and don't mess up with it.
", "time": "2023-03-31T01:38:14Z"}, {"author": "Martin Thomson", "text": "FWIW, wss: is not a real URI scheme; in every respect that matters, that is an https: URI.
", "time": "2023-03-31T02:02:27Z"}, {"author": "Martin Thomson", "text": "Maybe we should deprecate the ws and wss schemes...
", "time": "2023-03-31T02:02:56Z"}, {"author": "Tommy Pauly", "text": "Yeah wss is pretty ugly...
", "time": "2023-03-31T02:03:12Z"}, {"author": "Alan Frindell", "text": "Would it work better with a MAX_WEBSOCKETS, to mirror MAX_WEBTRANSORT_SESSIONS?
", "time": "2023-03-31T02:05:01Z"}, {"author": "David Benjamin", "text": "The original sin here was just that we implicitly said it was okay to have a wss-capable origin implement h2/h3 without h2+wss and h3+wss. That ship has sailed, but I think the right long-term strategy is to get out of that situation.
", "time": "2023-03-31T02:05:49Z"}, {"author": "Ted Hardie", "text": "note that ws and wss have a significant change compared to https; they do not admit of fragment identifiers. So deprecating them would require working out either whether that restriction can be dropped or how to retain it with an https uri.
", "time": "2023-03-31T02:06:03Z"}, {"author": "David Benjamin", "text": "Nothing else works this way. We don't expect you to support POST or CONNECT over h1 but not h2. You don't have to implement POST or CONNECT. But you have to implement it equally well in all our versions.
", "time": "2023-03-31T02:07:00Z"}, {"author": "David Benjamin", "text": "Paths is another example of where we already won't allow heterogeneous support. :-)
", "time": "2023-03-31T02:08:43Z"}, {"author": "David Benjamin", "text": "(Well, we do allow heterogenous support with HTTPS_1_1_REQUIRED, but that's mostly an escape valve and costs latency. But it does mean if you absolutely cannot follow the standard policy for some reason, you can still survive.)
", "time": "2023-03-31T02:10:47Z"}, {"author": "Benjamin Schwartz", "text": "I vote for Option 4.
", "time": "2023-03-31T02:12:07Z"}, {"author": "Martin Thomson", "text": "I guess you won't ever go from a failed h3 connection to an h2 attempt.
", "time": "2023-03-31T02:15:14Z"}, {"author": "Martin Thomson", "text": "wow, that queue got long, fast
", "time": "2023-03-31T02:17:18Z"}, {"author": "Martin Thomson", "text": "Yes, this is clearly in scope and interesting
", "time": "2023-03-31T02:17:35Z"}, {"author": "Martin Thomson", "text": "I tend to think that option 4 is great as an ideal, but it's not a solution we can depend on. We can't magic support for feature X across all HTTP versions.
", "time": "2023-03-31T02:20:11Z"}, {"author": "Kazuho Oku", "text": "As a lazy web site owner, status quo is easy to manage because there's nothing to do.
\nIf we are to add flags, I wonder what the risk that we have when the flags are set incorrectly (settings becoming out-of-sync).
I also disagree with @Benjamin Schwartz. Saying \"use WebTransport\" depends on a belief that people will just be able to fix their code. That's not how things work.
", "time": "2023-03-31T02:21:01Z"}, {"author": "Alex Chernyakhovsky", "text": "@Kazuho Oku isn't that the responsibility of your webserver? If you enable websockets, then when you take version n+1 it should do whatever the solution proposes, no? (I guess this is not trivial for HTTPS-RR as that's out-of-band)
", "time": "2023-03-31T02:21:42Z"}, {"author": "Benjamin Schwartz", "text": "@Martin Thomson We don't have a problem today. WebSockets work fine. They're just not as performant as WebTransport ... which will be true no matter what we do. I don't think we need to be polishing WebSockets.
", "time": "2023-03-31T02:21:51Z"}, {"author": "Martin Thomson", "text": "I really don't want to have too much configuration available outside of the confines of a connection.
", "time": "2023-03-31T02:21:59Z"}, {"author": "David Schinazi", "text": "+1, MASQUE supports all versions of HTTP but we are definitely not going to implement all 3
", "time": "2023-03-31T02:21:59Z"}, {"author": "Martin Thomson", "text": "@Benjamin Schwartz now we have an epistemological issue.
", "time": "2023-03-31T02:22:32Z"}, {"author": "Kazuho Oku", "text": "@Alex Chernyakhovsky I think my point is that if there's risk, server admins might not prefer to deploy this stuff, then it'd be meaningless to define these flags.
", "time": "2023-03-31T02:23:15Z"}, {"author": "Kazuho Oku", "text": "Because clients are doing their best already and we do not have a problem.
", "time": "2023-03-31T02:23:34Z"}, {"author": "Alex Chernyakhovsky", "text": "The behavior in the settings frame allows servers to opt-in to saying \"Definitely yes\" and \"definitely no\". Not saying anything leaves you in today's ambiguous status quo
", "time": "2023-03-31T02:23:52Z"}, {"author": "Alex Chernyakhovsky", "text": "So there's no cost to the feature?
", "time": "2023-03-31T02:24:01Z"}, {"author": "Martin Thomson", "text": "ALPN: no no NO NO NO NO!
", "time": "2023-03-31T02:24:12Z"}, {"author": "David Schinazi", "text": "I'll groan, but David has a point
", "time": "2023-03-31T02:24:21Z"}, {"author": "Martin Thomson", "text": "I mean, yeah, sure, but no
", "time": "2023-03-31T02:24:32Z"}, {"author": "David Benjamin", "text": "I think the way to think about ALPN is this is a one-off \"oops, we screwed up\" in allowing heterogenous support for websockets.
", "time": "2023-03-31T02:24:40Z"}, {"author": "David Schinazi", "text": "lol
", "time": "2023-03-31T02:24:41Z"}, {"author": "Eric Orth", "text": "I'm groaning, but I don't actually have any argument against the point.
", "time": "2023-03-31T02:24:50Z"}, {"author": "Martin Thomson", "text": "Websockets isn't worth it
", "time": "2023-03-31T02:24:54Z"}, {"author": "David Benjamin", "text": "And then we never, ever ever do it again. No more heterogeneous support like this.
", "time": "2023-03-31T02:24:57Z"}, {"author": "David Schinazi", "text": "I still believe we should have done a separate h3 ALPN per version of QUIC, but that shipped has sunk already
", "time": "2023-03-31T02:25:17Z"}, {"author": "Martin Thomson", "text": "I don't think that we can guarantee that this truly is a one-off. And if it is, Websockets just isn't worth it.
", "time": "2023-03-31T02:25:40Z"}, {"author": "David Benjamin", "text": "\"We don't care about WebSockets\" is also a fine answer. :-) But I hear there are other issues with h2 that we might want to fix. Ossification of frames and Lucas mentioned there was some priorities thing?
", "time": "2023-03-31T02:25:43Z"}, {"author": "Martin Thomson", "text": "What @Benjamin Schwartz really learned is that CONNECT is an abomination
", "time": "2023-03-31T02:26:44Z"}, {"author": "David Benjamin", "text": "The \"oops we screwed up, not doing that again\" story is an ALPN of \"h2.1\". The \"this is a general answer story\" is \"h2ws\". I do not care for the latter but it would solve the problem.
", "time": "2023-03-31T02:26:45Z"}, {"author": "Kazuho Oku", "text": "We can support redirect of CONNECT! Not sure we need though
", "time": "2023-03-31T02:28:48Z"}, {"author": "Alex Chernyakhovsky", "text": "CONNECT-UDP does not support HTTP redirects
", "time": "2023-03-31T02:29:35Z"}, {"author": "Erik Nygren", "text": "I would love to see this. Adopt!
", "time": "2023-03-31T02:31:06Z"}, {"author": "Martin Thomson", "text": "I have some new use cases for this.
", "time": "2023-03-31T02:32:18Z"}, {"author": "Adam Rice", "text": "WebSockets are used on 10% of page loads in Chrome. WebTransport is used in 0.001%. By which I mean to say, optimising WebSockets has concrete, immediate value to users.
", "time": "2023-03-31T02:32:24Z"}, {"author": "Martin Thomson", "text": "Details pending, sorry.
", "time": "2023-03-31T02:32:25Z"}, {"author": "Martin Thomson", "text": "@Adam Rice :scream:
", "time": "2023-03-31T02:32:56Z"}, {"author": "Martin Thomson", "text": "To clarify @Adam Rice that 10% number is quite concerning.
", "time": "2023-03-31T02:33:21Z"}, {"author": "Francesca Palombini", "text": "Thank you all!
", "time": "2023-03-31T02:33:53Z"}, {"author": "Jonathan Lennox", "text": "Analytics presumably
", "time": "2023-03-31T02:33:59Z"}, {"author": "Jonathan Lennox", "text": "Which is I agree alarming
", "time": "2023-03-31T02:34:10Z"}]