[HTTP/3] Detecting http session version on the backend (h2 vs h3)

[r00tb33r]

I need backend code to detect when the browser successfully switches over to h3 session following Alt-Svc response header.

I'm building a content submission system and need to leverage the network congestion relief benefits of QUIC. My system will discriminate and only allow uploads once the browser has successfully switched to h3, but I need some way to detect it in backend code, some session field or environment variable. Backend code may be PHP, or anything else, whatever works.

What is the way to detect HTTP protocol version of the session on the server side?

Essentially I expect the flow to be something like:
- the browser connects via h2 to the landing page
- Alt-Svc response header proposes h3
- JavaScript calls a page reload after a delay
- the browser is expected to connect via h3
- backend code detects h3 and responds with content submission form
- (otherwise the landing page with a page reload will repeat for some iterations until the browser jumps to h3)

That's how I picture it at the high level. I welcome any suggestions.

 

[serpent_driver]

What is the way to detect HTTP protocol version of the session on the server side?

phpinfo() does the trick.

$_SERVER['X_SPDY'] // HTTP3

$_SERVER['SSL_PROTOCOL'] // QUIC

$_SERVER['SERVER_PROTOCOL']

or use curl to get Alt-Svc response header.

 

[r00tb33r]

phpinfo() does the trick.

I'm fairly certain that fetches the PHP configuration, not the session type the particular browser connected with.

or use curl to get Alt-Svc response header.

That's on the client side. I need to know on the server side what protocol the browser connected with.

In other words, why would the server curl the client (and what would the client respond with, if the client isn't running any HTTP server!??)

 

[serpent_driver]

I'm fairly certain that fetches the PHP configuration, not the session type the particular browser connected with.

There is no session and you don't need any session data, because server variables and the protocol version used depends on user request.

That's on the client side. I need to know on the server side what protocol the browser connected with.

Alt-Svc is a response header, but the values of Alt-Svc header depends on what is supported by the browser.

 

[r00tb33r]

There is no session and you don't need any session data, because server variables and the protocol version used depends on user request.

I'll test this.

Alt-Svc is a response header, but the values of Alt-Svc header depends on what is supported by the browser.

Yeah, but I don't necessarily need to know the capabilities, I just need to know what the actual connection is. I suppose Alt-Svc would be missing entirely when the connection is already h3...? Maybe I can be sure we're connected via h3 that way?

 

[serpent_driver]

As said, use server variables or curl. Both will give you what you need.

 

[r00tb33r]

As said, use server variables or curl. Both will give you what you need.

I will test server variables and phpinfo().

However, I don't understand what curl has to do with any of it as it will create another HTTP session, info for which is not useful to me. I only need info about the current session.

 

[serpent_driver]

It is not about the session, but the request and the request decides what HTTP parameters are used. With curl you can simulate if your code works.

 

[r00tb33r]

It is not about the session, but the request and the request decides what HTTP parameters are used. With curl you can simulate if your code works.

Instead of "session" I should have said "request". HTTP 1.1 and above can indeed have sessions if it is kept "alive", consisting of one or multiple requests, and from what I understand connection protocol will remain the same within that session, between the multiple requests. So in that scenario the connection parameters for the request and the session can be considered interchangeable. Going from h2 to h3 would be starting a new session, h3 does not continue the h2 session.

Oh yeah, of course, I have curl and other tools at my disposal to test and simulate client connections. I'm just not very concerned about seeing the headers on the client side, there won't be any client side code to use it with.

I'll be back once I have observed the server side variables under different connection scenarios.

 

[serpent_driver]

Normally, you don't have to worry about whether HTTP/3 or QUIC is used because all modern browsers support QUIC. However, you must ensure that the connection is made via SSL or https, QUIC is activated in LiteSpeed WebAdmin, port 443 is used for https and the UDP port 443 for incoming and outgoing is not blocked or is open.

https://docs.litespeedtech.com/lsws/cp/cpanel/quic-http3/#troubleshooting-checklist

 

[r00tb33r]

Normally, you don't have to worry about whether HTTP/3 or QUIC is used because all modern browsers support QUIC. However, you must ensure that the connection is made via SSL or https, QUIC is activated in LiteSpeed WebAdmin, port 443 is used for https and the UDP port 443 for incoming and outgoing is not blocked or is open.

https://docs.litespeedtech.com/lsws/cp/cpanel/quic-http3/#troubleshooting-checklist

The initial connection will be TCP, typically h2, on all these modern browsers. (Alt-Svc response header advertises the h3 capability.) I have to make sure that content submissions are not happening over HTTP 1.1 or h2, that would be bad. TCP = no good.

This thread assumes that my LiteSpeed installation is already correctly configured for HTTP/3 capability. This thread is for the purpose of detecting that the browser client has connected with h3 on the server side, and deny service until the browser has successfully made the h3 request.

If you open a new browser session (incognito/private or whatever), and navigate here while monitoring network requests:
https://www.litespeedtech.com/
You will notice that the initial request completed as h2, with Alt-Svc response header. Once you refresh, if all is well it should complete the same request using h3, and there should not be Alt-Svc response header (because it's already h3, there is no "alternative service" to offer).

My application should only proceed once I can detect the client (the browser) has switched to h3, because I don't want clients sending multiple gigabytes of data to me over TCP.

 

[serpent_driver]

TCP has nothing to do with protocol version, because TCP is the underlying transport protocol used by HTTP, meaning TCP is always used. And there is no initial connection type. Either HTTP/3 is used or not, so I think you need to learn some basic knowledge what is what and what is used for what.

 

[r00tb33r]

TCP has nothing to do with protocol version, because TCP is the underlying transport protocol used by HTTP, meaning TCP is always used. And there is no initial connection type.

QUIC does not use TCP. QUIC is a reliable data transport over UDP.

No, TCP is not always used, and I need to make sure it isn't. But it always begins with TCP as browsers don't assume a server has HTTP/3 or QUIC capability, that part is true.

Either HTTP/3 is used or not, so I think you need to learn some basic knowledge what is what and what is used for what.

False, and you have some learning to do.

And there is no initial connection type.

Also false.

 

[serpent_driver]

QUIC does not use TCP. QUIC is a reliable data transport over UDP.

Yes, but QUIC needs HTTP/3 and HTTP/3 needs TCP.

 

[r00tb33r]

Yes, but QUIC needs HTTP/3

False. There are whole applications that just use QUIC protocol "sockets". If I wasn't using UDT (the precursor to QUIC), I'd be using QUIC in my existing applications.

QUIC is transport layer. HTTP/3 is application layer protocol built upon it, but QUIC doesn't care what application layer data is sent across it, it doesn't need to be HTTP.

By the way, for this very reason on HTTP/3 servers listen on port 443 for both TCP and UDP packets. Once the browser switches to h3 it will be using UDP on port 443.

 

[Yogurteg]

No, TCP is not always used, and I need to make sure it isn't. But it always begins with TCP as browsers don't assume a server has HTTP/3 or QUIC capability, that part is true.

Almost) You can begin h3 connection for all users (who supports h3) instantly.

 

[r00tb33r]

Almost) You can begin h3 connection for all users (who supports h3) instantly.

Yeah, possible, but major web browsers don't do it right now, meaning Chrome, Firefox, etc. Sure, you can specify it with a command line switch, but you won't expect your visitors to do that just to connect to you.

 

[serpent_driver]

@r00tb33r
I'm curious. Why and what do you need a quic detection for?

 

[r00tb33r]

@r00tb33r
I'm curious. Why and what do you need a quic detection for?

It's in the OP.

I'm building a content submission system and need to leverage the network congestion relief benefits of QUIC. My system will discriminate and only allow uploads once the browser has successfully switched to h3, but I need some way to detect it in backend code, some session field or environment variable. Backend code may be PHP, or anything else, whatever works.

I have an existing custom UDP-based delivery application (UDT protocol) that I'm trying to retire and instead leverage a web-based delivery system using QUIC. TCP deliveries will not be acceptable.

WebTransport would be another alternative, but it is less widely adopted for now. Chrome is not feature complete and Safari does not support it at all. A significant portion of content submissions I receive are uploaded from Macs. (I had to write two native client applications for this, Windows and Mac.)

I need to catch up on updating this thread as I'm doing tests.

 

[serpent_driver]

And what advantage do you hope to gain from this? The use of quic primarily serves to improve the deficits in connection establishment with https, because the TCP protocol tends to neglect SSL. Wouldn't it be better to focus on http/3?

Nevertheless, I don't understand how you can use PHP to gain any kind of advantage by recognizing quic?! Especially since http/3 is not a replacement for http/2.