Repository navigation
--http2-prior-knowledge still offers http/1.1 #9963
Description
Activity
Tells curl to issue its non-TLS HTTP requests using HTTP/2 without HTTP/1.1 Upgrade. It requires prior knowledge that the server supports HTTP/2 straight away. HTTPS requests will still do HTTP/2 the standard way with negotiated protocol version in the TLS handshake.
Do you see different results when http/1.1 is not sent in the ALPN?
prior knowledge is pointless over HTTPS as then the negotiation is done before HTTP starts and with no "penalty". Without HTTPS you can avoid a round-trip if you know can speak h2 immediately.
I suppose we could use it there to mean "I really only want h2 and nothing else"
Do you see different results when http/1.1 is not sent in the ALPN?
With #9964 yes. I had to change the code of exn.st but basically the previous code would choose http/1.1 over h2 if the ALPN request said http/1.1 is available.
I suppose we could use it there to mean "I really only want h2 and nothing else"
That's what I thought the argument would do after reading the documentation. But it looks like the manpage disagrees then. If you think the behaviour could be changed I think it would be a good thing. If you don't want to change the behaviour maybe a new argument could be added?
prior knowledge is pointless over HTTPS as then the negotiation is done before HTTP starts and with no "penalty". Without HTTPS you can avoid a round-trip if you know can speak h2 immediately.
The TLS handshake can be avoided by using a saved ssl session.
Applications which use libcurl and seek to extract maximum performance, take advantage of saved SSL sessions. It may or may not be supported in the current "curl" command line application.
Regards
The TLS handshake can be avoided by using a saved ssl session.
Correct, but that is entirely separate from this proposed change. libcurl already features a session cache for that.
The TLS handshake can be avoided by using a saved ssl session.
Correct, but that is entirely separate from this proposed change. libcurl already features a session cache for that.
My point is that prior knowledge is not pointless over HTTPS for the stated reason that the TLS handshake is slow, because that reason is not valid. TLS handshake is not guaranteed to be slow. The TLS handshake can be as fast as a 3-way TCP handshake in some cases, such as the example I gave, where session caches are in use.
This is not a bug, but could be made into a future feature if someone wants to work on it.
Hi Team,
I understand its kind of old thread, but is this issue fixed in any release. I understand the fix provided by Kit-ty-Kate had merge conflicts.
But, --http2-prior-knowledge doesn't work as defined and it really doesn't solve the problem of wanting to send only H2 in ALPN header.
Please let me know if there is any work-around or any released package which has this kind of working. ( I couldn't find it in any release package and none of the change logs mention it)
Thanks
But, --http2-prior-knowledge doesn't work as defined and it really doesn't solve the problem of wanting to send only H2 in ALPN header.
That's not what this option is for, so I don't think saying "doesn't work as defined" is correct.
But as said before: we/someone could make it work like this.
- added a commit that references this issue
on Jul 23, 2024 I stand corrected for my mentioning of --http2-prior-knowledge working, and thanks a lot for changing the behaviour and committing it.
- added a commit that references this issue
on Aug 4, 2024
I did this
I expected the following
but got
I expected to not see
ALPN: offers http/1.1given what the documentation says on the website (https://curl.se/docs/http2.html):curl/libcurl version
operating system