Before I open a support case, just wondering if anyone else has experienced an issue with the latest update and VS that use HTTP2 profiles?
Specifically seems to impact Firefox users who just get a HTTP400 response from the pool members. Node logs show the request being malformed hence the error.
Removing HTTP2 profile clears the issue and is the workaround I'm running with currently.
I have the same issue. In 13.1 there is no longer the NPN mode in the advanced settings for the http2 profile only ALPN and Always. I was about to open a ticket but as a workaround I have removed the http2 profile from my virtual servers.
That's interesting Dan. My issue seems isolated to Firefox users but I wasn't sure if removal of NPN would cause issues. Our users mainly still user FF v41 so I thought perhaps ALPN may not be supported properly in that old version, however I've just tried the latest FF Quantum release against one of my test VS with http2 profile applied and I see the same issue.
ALPN should be fully supported in that version, so I'm not sure the root cause can be pinned on removal of NPN.
Would be interested to hear how you get on - I'll keep this thread updated also as/when I make any progress.
We received an Engineering hot fix for 220.127.116.11, but I don't know when this will be included in an official release.
18.104.22.168 has been released yesterday. In the list of known issues in the release notes:
703191-2 2-Critical HTTP2 requests may contain invalid headers when sent to servers
Details of the issue in the release notes:
703191-2 : HTTP2 requests may contain invalid headers when sent to servers
Component: Local Traffic Manager
HTTP requests handled by an HTTP/2 virtual server may have blank header names when proxied through to the server or when handled via iRules.
-- Virtual server has the HTTP/2 profile assigned.
-- Client and the BIG-IP system negotiate/use HTTP/2.
HTTP/2 applications may generate CSRF-related errors. Alternately, the server may return intermittent (and from the client's perspective, spurious) 400 Bad Request responses.
There is no workaround other than to remove the HTTP/2 profile from the virtual server.
Thanks Nav - shame it's not been fixed in 22.214.171.124 considering there's been an EHF available for it!
At least we have a bug ID and presence in Known Issues though to keep an eye on.
There are some bugs related to HTTP2 in the release notes:
See the section "Known Issues in BIG-IP v13.1.x".
There are explanation and workaround at the end, and some may have already been fixed for 126.96.36.199.
Thanks Leonardo - unfortunately the listed bugs don't correlate with the issues we're having.
Looks like I'll have to raise a support case!
This is getting ridiculous. HTTP/2 has to be disabled in 13.1.0.X if we want to allow Firefox users to still use our services.
Could you someone from F5 help us here?
In case you think I am from F5, I am not.
It is better you make your complain or request via a support case, DevCentral is not the correct place for that.
Don't get me wrong, Leonardo. I was not implying you are from F5. I was rhetorically asking this question in order to find a way to attract attention from F5 insiders that are also scouting DevCentral.
I have also my fair share of experience to know that opening a support case does sometimes not provide much more information. If we could get someone closer to the devs, we could have more precise information.
Any news on this issue? Did you get any answer from the support ?
We are facing exactly the same problem, and have fixed it for now by disabling HTTP/2.
The same issue is affecting us on 188.8.131.52 (we've opened a support call C2634426, awaiting a response). Logging the request headers on the F5 seems to show the Accept header with an empty header name, though a packet capture of the request from Firefox looks sane, so it looks like there are some issues with header processing.
We've had a response to our support call to say this is a bug:
ID703191 HTTP2 requests may contain invalid headers when sent to servers
Good news Mat,
Do you have any idea when it will be patched ?
Version 184.108.40.206 is out now but there's no mention of a fix for any http2 issue. I guess we need to wait. Our website had to disable http2 since none of our Firefox visitors were able to successfully connect. Kind of a big deal.
I've been having the same header issue with Firefox, turning on http2 changes "accept: text/css,/;q=0.1\r\" to ": text/css,/;q=0.1\r\n"
We run 220.127.116.11 and are still facing the HTTP Error 400 "The request has an invalid header name" when using the http2 profile.
The 18.104.22.168 release note still mentions bug 703191-2 in the list of known bugs (and so does 22.214.171.124 release note). Is F5 working on this issue ?