Would you please file that as a bug report with patch following the instructions at https://make.ww.wp.xz.cn/core/handbook/testing/reporting-bugs/ ?
That way, you’ll get credit on the next release when it’s accepted, even if it just inspires a different change. 🙂
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
You can submit a trac ticket but that’s not correct.
Switching to https and getting HTTP/1.1 405 Method Not Allowed is still valid. The application status code doesn’t become HTTPS/1.1 405 Method Not Allowed when you are using an encrypted transport.
For example using curl to view the headers https://www.google.com/ will get you an HTTP/1.1 result code.
$ curl -I https://www.google.com/
HTTP/1.1 200 OK
After the TLS setup and exchange, the application protocol is still HTTP/1.1. I haven’t checked with HTTP/2 but I’m pretty sure the result code will be similar.
Edit: Right, and that’s why I need coffee. HTTP/2 is what you are talking about as you clearly stated.
My bad. I focused on $_SERVER['SERVER_PROTOCOL' when you are clearly talking about hardcoding 1.1 as the protocol version number when it should detect it correctly in preparation of HTTP/2.
Someone beat me to the ticket after obviously having read this very thread.
Moderator
Jan Dembowski
(@jdembowski)
Forum Moderator and Brute Squad
What’s the trac ticket URL? You can always improve on the code and suggest better protocol version checks to validate HTTP/1.1 and HTTP/2.0.
This has nothing to do with validating. It is what WordPress is sending back to the client in response to an improper HTTP METHOD request other than “POST”.
The only piece of information that WordPress has available to it on HTTP server protocol is through:
$_SERVER['SERVER_PROTOCOL']
It must not fake the client out thinking it is something other than what the HTTP server is reporting.
#37863 got re-opened.