A protocol version number[1][2] (PVN) is an integer used to check for incompatibilities between the player’s client and the server they are trying to connect to.
Client and server versions with the same protocol version are compatible with each other. For example, a client running Java Edition 1.8.9 can connect to a server running Java Edition 1.8, as both have a protocol version of 47.
Upon attempting to join a multiplayer server, the game checks if the client has a protocol version newer or older than the selected server; if it does, the game then alerts the player that their client (or the server) is outdated.
All versions, including minor releases and development versions on both Java and Bedrock editions, have their own protocol version. The version takes the form of an ever-increasing positive integer unlike client versions. Since 1.16.4-pre1, protocol versions of Java Edition development releases take the form of very large numbers best represented using hexadecimal (represented by the prefix «0x» in the protocol version tables, starting from 0x40000001 (1073741825 in hexadecimal)). Protocol versions may occasionally be skipped between major releases.
Each Minecraft build since 18w47b specifies its current protocol version in the version.json file, found in the root directory of the client and server jars.
Since beta 1.2.0.22, the protocol version can be viewed by going into Profile Settings and scrolling down to the bottom. The protocol version appears in front of the text saying «Protocol Version:». It can also appears on the beta text in front of the text saying «cli-pn«.
The latest Java Edition release version, 1.19.4, has a protocol version of 762.
The latest Java Edition development version, 1.20 Pre-release 6, has a protocol version of dec: 1073741963 hex: 4000008B.
The latest Bedrock Edition release version, 1.19.83, has a protocol version of 582.
The latest Bedrock Edition development version, beta 1.20.10.20, has a protocol version of 592.
I was trying to get and analyse extended information from various websites, the only sustainable solution I could find is to using Selenium, with following peace of could get any information, including protocol version: «H2», «HTTP/1.1» etc.
As you can see from following peace of response, you will be able to get pretty much any kind of information you could possibly need (including protocol version):
{«message»:{«method»:»Network.responseReceived»,»params»:{«frameId»:»755A984985C3F1263469B348C78A4AA5″,»loaderId»:»2116D4C83A7C6EFD017CC5BC6814FCAB»,»requestId»:»2116D4C83A7C6EFD017CC5BC6814FCAB»,»response»:{«connectionId»:41,»connectionReused»:false,»encodedDataLength»:9595,»fromDiskCache»:false,»fromPrefetchCache»:false,»fromServiceWorker»:false,»headers»:{«cache-control»:»no-cache,
must-revalidate»,«content-encoding»:»gzip»,»content-language»:»en»,»content-type»:»text/html; charset=utf-8″,»date»:»Sun, 19 Apr 2020 12:37:09 GMT»,»expires»:»Sun,
19 Nov 1978 05:00:00
GMT»,»server»:»nginx»,»status»:»200″,»vary»:»Accept-Encoding»,»x-content-type-options»:»nosniffnnosniff»,»x-frame-options»:»SAMEORIGIN»,»x-generator»:»Drupal
7
(http://drupal.org)»,»x-powered-by»:»PleskLin»},»mimeType»:»text/html»,«protocol»:»h2″,»remoteIPAddress»:»195.210.46.29″,»remotePort»:443,»requestHeaders»:{«:authority»:»www.WEBSITENAME.com»,»:method»:»GET»,»:path»:»/»,»:scheme»:»https»,»accept»:»text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9″,»accept-encoding»:»gzip,
deflate,
br»,»accept-language»:»en-US,en;q=0.9″,»sec-fetch-dest»:»document»,»sec-fetch-mode»:»navigate»,»sec-fetch-site»:»none»,»sec-fetch-user»:»?1″,»upgrade-insecure-requests»:»1″,»user-agent»:»Mozilla/5.0
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/81.0.4044.113
Safari/537.36″},»securityDetails»:{«certificateId»:0,»certificateTransparencyCompliance»:»compliant»,»cipher»:»AES_128_GCM»,»issuer»:»Let’s
Encrypt Authority
X3″,»keyExchange»:»ECDHE_RSA»,»keyExchangeGroup»:»P-256″,»protocol»:»TLS
1.2″,»signedCertificateTimestampList»:[{«hashAlgorithm»:»SHA-256″,»logDescription»:»Let’s
Encrypt ‘Oak2020’
log»,»logId»:»E712F2B0377E1A62FB8EC90C6184F1EA7B37CB561D11265BF3E0F34BF241546E»,»origin»:»Embedded
in
certificate»,»signatureAlgorithm»:»ECDSA»,»signatureData»:»30440220600B7A7DE2155D200AE2179CE5E297DC6AB9118E57934440C20E25E33C420ADC02201DC0B323CDCA6BF85100E4816B1405BA5BBB2F41EB225CABCBA4CB5C0513E449″,»status»:»Verified»,»timestamp»:1.586426567863e+12},{«hashAlgorithm»:»SHA-256″,»logDescription»:»Google
‘Argon2020’
log»,»logId»:»B21E05CC8BA2CD8A204E8766F92BB98A2520676BDAFA70E7B249532DEF8B905E»,»origin»:»Embedded
in
certificate»,»signatureAlgorithm»:»ECDSA»,»signatureData»:»3046022100AF260074C39A0F1294C8038BAEE0B85F984C7EC80D10203D6AAAC1BB8B5CDF1D022100ECE351015B9375A3F85CA84EC5CB606A5453AF34AFFDC25C5D32BC938A01FD67″,»status»:»Verified»,»timestamp»:1.586426567862e+12}],»subjectName»:»WEBSITENAME.com»,»validFrom»:1586422967,»validTo»:1594198967},»securityState»:»secure»,»status»:200,»statusText»:»»,»timing»:{«connectEnd»:399.532,»connectStart»:163.118,»dnsEnd»:163.118,»dnsStart»:163.073,»proxyEnd»:-1,»proxyStart»:-1,»pushEnd»:0,»pushStart»:0,»receiveHeadersEnd»:2137.345,»requestTime»:51622.890236,»sendEnd»:399.969,»sendStart»:399.759,»sslEnd»:399.526,»sslStart»:281.492,»workerReady»:-1,»workerStart»:-1},»url»:»https://www.WEBSITENAME.com/»},»timestamp»:51625.02969,»type»:»Document»}},»webview»:»755A984985C3F1263469B348C78A4AA5″}
Upgraded socketloop.com’s NGINX web server to serve via HTTP/2 and wanted to find out if Golang can detect the HTTP/2 protocol version. However, at this moment (Go 1.5), Golang’s client will always return protocol version HTTP/1.1
From https://golang.org/pkg/net/http/#Request :
// The protocol version for incoming requests.
// Client requests always use HTTP/1.1.
Pretty sure HTTP/2 detection is available at https://godoc.org/golang.org/x/net/http2#ClientConn, but better to wait till it is incorporated into Go 1.6.
Here is a simple example on how to find out the protocol version use by the client in making request to server.
package main
import (
"fmt"
"net/http"
"os"
)
func main() {
client := &http.Client{}
url := "https://www.google.com"
resp, err := client.Get(url) // can use http directly instead of client
if err != nil {
fmt.Println(err)
os.Exit(1)
}
// get protocol version
protocol := resp.Request.Proto
fmt.Println("URL is : ", url)
fmt.Println("Protocol is : ", protocol)
}
Sample outputs :
URL is : //www.socketloop.com
Protocol is : <—— missing protocol!
URL is : https://www.socketloop.com
Protocol is : HTTP/1.1
URL is : http://www.google.com
Protocol is : HTTP/1.1
URL is : https://www.google.com
Protocol is : HTTP/1.1
Apparently, attempt to get protocol version from NON-HTTPS (//www.socketloop.com) version of socketloop.com will return empty string. Upon further investigation with curl -I command, Golang’s net/http.Request.Proto will only returns value if the HTTP status code is 200 — OK.
>curl -I //www.socketloop.com
HTTP/1.1 301 Moved Permanently
>curl -I https://www.socketloop.com
HTTP/1.1 200 OK
Tried to improve the protocol detection by getting Request header information from the final/effective URL, but it seems that after resolving to the final/effective URL, the protocol variable will still be returned as empty string. (See how to get the HTTP status code https://www.socketloop.com/tutorials/golang-intercept-and-compare-http-response-code-example)
Hence, it is best to check for the protocol string length first before displaying the version.
package main
import (
"fmt"
"net/http"
"os"
)
func main() {
client := &http.Client{}
url := "//www.socketloop.com" // has 301 redirect
resp, err := client.Get(url)
if err != nil {
fmt.Println(err)
os.Exit(1)
}
// get protocol version
protocol := resp.Request.Proto
if len(protocol) > 0 {
fmt.Println("URL is : ", url)
fmt.Println("Protocol is : ", protocol)
} else {
fmt.Println("URL is : ", url)
fmt.Println("Unable to determine protocol version. Check URL with curl -I to see if HTTP status code is 301")
fmt.Println("Golang will resolve to the final/effective URL and will not return HTTP status 301, but 200. However, it will still return empty string for Proto ")
}
}
Output :
With 301 redirect :
URL is : //www.socketloop.com
Unable to determine protocol version. Check URL with curl -I to see if HTTP status code is 301
Golang will resolve to the final/effective URL and will not return HTTP status 301, but 200. However, it will still return empty string for Proto
and with 200 — OK :
URL is : https://www.socketloop.com
Protocol is : HTTP/1.1
References :
https://godoc.org/golang.org/x/net/http2
https://golang.org/pkg/net/http/#Request
https://www.socketloop.com/tutorials/golang-intercept-and-compare-http-response-code-example
https://www.socketloop.com/tutorials/golang-get-final-or-effective-url-with-request-url-example
PuTTY
In Session, Logging, select the «SSH packets and raw data» radio button. Select the log file as putty.log in a location of your choice. Make the connection. You should see:
Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
See below for details on what SSH-2.0 means.
Other Methods
You could also try using the telnet client, but point to port 22:
telnet test1 22
When you connect you will see:
Trying 192.168.144.145…
Connected to test1.
Escape character is ‘^]’.
SSH-2.0-OpenSSH_5.3
The last line is the one to look for:
SSH-2.0-OpenSSH_5.3
If it says SSH-2.0 then that is good, the SSH server you connected to supports only SSH protocol version 2. It will not support connections from SSH V1 protocol clients.
If however you see:
SSH-1.99-OpenSSH_5.3
Then that means that the server end is still supporting SSH protocol version 1. It has something like this in it’s sshd_config file:
Protocol 1,2
Protocol 1 is vulnerable and should not be used.
So to get that straight. If you see SSH-2 when you telnet to port 22 of the remote server then you can only be using SSH protocol version 2 as the server does not support protocol 1.
As per cstamas answer above, the -v flag will show a line:
debug1: Remote protocol version 1.99, remote software version OpenSSH_5.3
or:
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
You want to see version 2.0 there.
Try to pass a User-Agent string, like this:
import requests
headers = {'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36'}
URL = 'http://serveraddress'
page = requests.get(URL, headers=headers)
print(page.text)
Background: Working with a legacy Shoutcast streaming audio server, I was getting the following error:
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine('ICY 200 OKrn'))
I noticed, too, that wget attempted to stream the data, even when given an -O output directive.
Comparing with Developer Tools in Chrome, I could see several request headers that the browser set, including User-Agent. I copied the User-Agent value from Chrome and used it as a parameter in a requests.get function.