> But at least it exists, and perhaps if adoption continues to grow, eventually it will be possible to require HTTP/3 without losing a significant number of users. For now, it’s only something you can do on the side - you still have to have a traditional HTTPS fallback.
It's estimated that 75% of browsers (well... I guess user agents) on…
> But at least it exists, and perhaps if adoption continues to grow, eventually it will be possible to require HTTP/3 without losing a significant number of users. For now, it’s only something you can do on the side - you still have to have a traditional HTTPS fallback.
It's estimated that 75% of browsers (well... I guess user agents) on the net support HTTP/3 acording to wikipedia
> Which brings us to the third item on the list, and the real sticking point. As far as I’m aware, no current or planned future Web API ever lets you do number three. There are many new web “technologies” swarming around the custom packet idea (WebRTC, WebSockets, WebTransport), but to the best of my knowledge, all of them require an HTTPS connection to be made first, so your “custom packet” servers still need to implement all of HTTPS anyway.
Right, WebTransport over HTTP/3 is an option.
Your theoretical "I am writing a UDP library but want to isolate my HTTPS stuff somewhere else" situation... I mean beyond the fact that there are many options to strip away the abstraction, if you're writing a custom UDP protocol but are afraid of HTTPS, HTTP/3, that is a bit odd to say the least!
Now for technical concerns:
TCP is, of course, TCP. Ordered, etc. And so if you're sitting there with HTTP over TCP, well... firewalls etc are very straightforward. There is a very limited amount of things going on, so it is easy to control. UDP is completely the opposite, as you really can only do destination-based filtering.
So you only have source and destination as an option. One option is to say "ok you can't do cross origin UDP". In that case there's the reality that you control the client and the server, so to speak, so... just use WebTransport! You have your option there.
Another scenario, where you say "we'll allow all cross-origin UDP. Users can say accept/deny". Some random site decides they don't like you, and add some JS to DDOS you. They ask users to accept (and users do it cuz it's one of those websites). Users end up DDOSing you. The "approve/deny" flow works well for when you are the potential victim, but in the DDOS model you are not "consenting".
You might say "well, they can do that from their machines by dowloading software", and you are right.
How is this different from the image tag? The magic of HTTP makes actually filtering out stuff real straightforward. XHR stuff is different from handling black box UDP. It's actually easier, and because there is a protocol it's much easier to cut things off, not wait around while receiving garbage, etc. And middleware can also handle it on their end. Enterprises have networks to run.This is how Cloudflare exists and does its stuff/reject connections real easily. Raw, black-boxed UDP? All off the table.
You could make a protocol off of UDP that does a bunch of stuff to make this easier. But now... what? Are you just making TCP? You're gonna make your own magical protocol to avoid implementing WebTransport?
So in that case... you would probably want to establish some handshake for the connection. You might want some origin-based tokens similar to how people set up CSRF tokens for POST. And there's all these other concerns.
And now you have ended up adding some layer over UDP anyways!
Your claim is that you can't just go raw UDP mode in browsers. This is true. But WebTransport exists and you can use that to get all the advantages of UDP mode, while also taking advtange of the security benefits of the HTTP protocol.
So serious people will look at WebTransport, and correctly identify that it fits within models they are used to work in, and they can get all the advantages of UDP speed.
So your ask here isn't "let me have access to UDP", it's "let's add a UDP-based API that will make it easier to distribute DDOS-y software and generally create more unauditable traffic and make network QoS harder". Remember, you have access to UDP if you deal with WebTransport! And you might think that's not important. Many people disagree.
The technical claim is that a raw UDP connection that is assumed to have any content is harder to automatically filter out or otherwise manage, but the wrapping cost of WebTransport over HTTP/3 is small enough that browser can offer UDP to users, so long as they are using that.
And, of course, you can give yourself raw UDP in Javascript, if you're using something line Node. You're asking for a raw UDP API inside of browsers.
> But at least it exists, and perhaps if adoption continues to grow, eventually it will be possible to require HTTP/3 without losing a significant number of users. For now, it’s only something you can do on the side - you still have to have a traditional HTTPS fallback.
It's estimated that 75% of browsers (well... I guess user agents) on the net support HTTP/3 acording to wikipedia
> Which brings us to the third item on the list, and the real sticking point. As far as I’m aware, no current or planned future Web API ever lets you do number three. There are many new web “technologies” swarming around the custom packet idea (WebRTC, WebSockets, WebTransport), but to the best of my knowledge, all of them require an HTTPS connection to be made first, so your “custom packet” servers still need to implement all of HTTPS anyway.
Right, WebTransport over HTTP/3 is an option.
Your theoretical "I am writing a UDP library but want to isolate my HTTPS stuff somewhere else" situation... I mean beyond the fact that there are many options to strip away the abstraction, if you're writing a custom UDP protocol but are afraid of HTTPS, HTTP/3, that is a bit odd to say the least!
Now for technical concerns:
TCP is, of course, TCP. Ordered, etc. And so if you're sitting there with HTTP over TCP, well... firewalls etc are very straightforward. There is a very limited amount of things going on, so it is easy to control. UDP is completely the opposite, as you really can only do destination-based filtering.
So you only have source and destination as an option. One option is to say "ok you can't do cross origin UDP". In that case there's the reality that you control the client and the server, so to speak, so... just use WebTransport! You have your option there.
Another scenario, where you say "we'll allow all cross-origin UDP. Users can say accept/deny". Some random site decides they don't like you, and add some JS to DDOS you. They ask users to accept (and users do it cuz it's one of those websites). Users end up DDOSing you. The "approve/deny" flow works well for when you are the potential victim, but in the DDOS model you are not "consenting".
You might say "well, they can do that from their machines by dowloading software", and you are right.
How is this different from the image tag? The magic of HTTP makes actually filtering out stuff real straightforward. XHR stuff is different from handling black box UDP. It's actually easier, and because there is a protocol it's much easier to cut things off, not wait around while receiving garbage, etc. And middleware can also handle it on their end. Enterprises have networks to run.This is how Cloudflare exists and does its stuff/reject connections real easily. Raw, black-boxed UDP? All off the table.
You could make a protocol off of UDP that does a bunch of stuff to make this easier. But now... what? Are you just making TCP? You're gonna make your own magical protocol to avoid implementing WebTransport?
So in that case... you would probably want to establish some handshake for the connection. You might want some origin-based tokens similar to how people set up CSRF tokens for POST. And there's all these other concerns.
And now you have ended up adding some layer over UDP anyways!
Your claim is that you can't just go raw UDP mode in browsers. This is true. But WebTransport exists and you can use that to get all the advantages of UDP mode, while also taking advtange of the security benefits of the HTTP protocol.
So serious people will look at WebTransport, and correctly identify that it fits within models they are used to work in, and they can get all the advantages of UDP speed.
So your ask here isn't "let me have access to UDP", it's "let's add a UDP-based API that will make it easier to distribute DDOS-y software and generally create more unauditable traffic and make network QoS harder". Remember, you have access to UDP if you deal with WebTransport! And you might think that's not important. Many people disagree.
The technical claim is that a raw UDP connection that is assumed to have any content is harder to automatically filter out or otherwise manage, but the wrapping cost of WebTransport over HTTP/3 is small enough that browser can offer UDP to users, so long as they are using that.
And, of course, you can give yourself raw UDP in Javascript, if you're using something line Node. You're asking for a raw UDP API inside of browsers.