HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR

[danel1]

Hi there
We are seeing the following problem:

• When trying to do a HEAD on a PHP-File we get n "PROTOCOL_ERROR(0x01) / HTTP/2 stream 1 was not closed cleanly" error message.
• GET works fine.
• Only happens with HEAD to PHP-Files. HEAD to HTML Files for example works fine.
• Happens with curl but also with nghttp-Client..
• Does not happen with nginx
• Apache v2.4.34 / libnghttp2 v1.32.0 / curl v7.61.0 / FreeBSD 10.4

Thanks for taking a look at it.

curl HEAD output:

$ curl -4 --http2 -I -v https://danii.ch/phpinfo.php
*   Trying x.x.x.x...
* TCP_NODELAY set
* Connected to danii.ch (x.x.x.x) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.danii.ch
*  start date: May  5 00:00:00 2018 GMT
*  expire date: Nov 20 12:00:00 2018 GMT
*  subjectAltName: host "danii.ch" matched cert's "danii.ch"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Encryption Everywhere DV TLS CA - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a794c7f90)
> HEAD /phpinfo.php HTTP/2
> Host: danii.ch
> User-Agent: curl/7.61.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
* Connection #0 to host danii.ch left intact
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

curl GET output:

*   Trying x.x.x.x...
* TCP_NODELAY set
* Connected to danii.ch (x.x.x.x) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.danii.ch
*  start date: May  5 00:00:00 2018 GMT
*  expire date: Nov 20 12:00:00 2018 GMT
*  subjectAltName: host "danii.ch" matched cert's "danii.ch"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=Encryption Everywhere DV TLS CA - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5613edf1df90)
> GET /phpinfo.php HTTP/2
> Host: danii.ch
> User-Agent: curl/7.61.0
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200 
HTTP/2 200 
< date: Mon, 06 Aug 2018 13:39:32 GMT
date: Mon, 06 Aug 2018 13:39:32 GMT
< server: Apache/2.4
server: Apache/2.4
< content-type: text/html; charset=UTF-8
content-type: text/html; charset=UTF-8

< 
* Connection #0 to host danii.ch left intact

HEAD via Google Chrome Console:

var http = new XMLHttpRequest();
http.open("HEAD", "https://prognolite.com/header.php");
http.send(); console.log(http);

Failed to load resource: net::ERR_SPDY_PROTOCOL_ERROR

[icing]

Looks like the h2 protocol needs to forcefully close response bodies in case the request handler sends a body on HEAD requests. This seems to be the difference between php and static file handler.

[danel1]

So by what could this be caused? And how do you think this could be fixed?

[icing]

I need to add a test case for this and make a fix in the h2 code. You are able to build mod_http2 from here and verify a fix?

[danel1]

Yeah that should be possible.

[icing]

Ok, question is, can you provide me a mini config how you setup your php? There are several possibilities and I'd like to make sure we are looking at the same one.

(I have python cgi setup in my standard h2 tests, but they do not expose that problem)

[danel1]

Sure:

• FreeBSD 10.4
• Apache 2.4.34 (mpm_worker)
• PHP 7.2 (php-fpm)
• MariaDB 10.1
• Protocols h2 h2c http/1.1
• Apache Options:

	ACCESS_COMPAT  : on
	ACTIONS        : on
	ALIAS          : on
	ALLOWMETHODS   : on
	ASIS           : on
	AUTHNZ_FCGI    : on
	AUTHNZ_LDAP    : off
	AUTHN_ANON     : on
	AUTHN_CORE     : on
	AUTHN_DBD      : on
	AUTHN_DBM      : on
	AUTHN_FILE     : on
	AUTHN_SOCACHE  : on
	AUTHZ_CORE     : on
	AUTHZ_DBD      : on
	AUTHZ_DBM      : on
	AUTHZ_GROUPFILE: on
	AUTHZ_HOST     : on
	AUTHZ_OWNER    : on
	AUTHZ_USER     : on
	AUTH_BASIC     : on
	AUTH_DIGEST    : on
	AUTH_FORM      : on
	AUTOINDEX      : on
	BROTLI         : on
	BUCKETEER      : off
	BUFFER         : on
	CACHE          : on
	CACHE_DISK     : on
	CACHE_SOCACHE  : on
	CASE_FILTER    : off
	CASE_FILTER_IN : off
	CERN_META      : on
	CGI            : on
	CGID           : on
	CHARSET_LITE   : on
	DATA           : on
	DAV            : on
	DAV_FS         : on
	DAV_LOCK       : on
	DBD            : on
	DEFLATE        : on
	DIALUP         : on
	DIR            : on
	DUMPIO         : on
	ECHO           : off
	ENV            : on
	EXAMPLE_HOOKS  : off
	EXAMPLE_IPC    : off
	EXPIRES        : on
	EXT_FILTER     : on
	FILE_CACHE     : on
	FILTER         : on
	HEADERS        : on
	HEARTBEAT      : on
	HEARTMONITOR   : on
	HTTP2          : on
	IDENT          : off
	IMAGEMAP       : on
	INCLUDE        : on
	INFO           : on
	IPV4_MAPPED    : off
	LBMETHOD_BYBUSYNESS: on
	LBMETHOD_BYREQUESTS: on
	LBMETHOD_BYTRAFFIC: on
	LBMETHOD_HEARTBEAT: on
	LDAP           : off
	LOGIO          : on
	LOG_DEBUG      : on
	LOG_FORENSIC   : on
	LUA            : off
	LUAJIT         : off
	MACRO          : on
	MD             : off
	MIME           : on
	MIME_MAGIC     : on
	MPM_EVENT      : off
	MPM_PREFORK    : off
	MPM_SHARED     : on
	MPM_WORKER     : on
	NEGOTIATION    : on
	OPTIONAL_FN_EXPORT: off
	OPTIONAL_FN_IMPORT: off
	OPTIONAL_HOOK_EXPORT: off
	OPTIONAL_HOOK_IMPORT: off
	PROXY          : on
	PROXY_AJP      : on
	PROXY_BALANCER : on
	PROXY_CONNECT  : on
	PROXY_EXPRESS  : on
	PROXY_FCGI     : on
	PROXY_FDPASS   : on
	PROXY_FTP      : on
	PROXY_HCHECK   : on
	PROXY_HTML     : on
	PROXY_HTTP     : on
	PROXY_HTTP2    : on
	PROXY_SCGI     : on
	PROXY_UWSGI    : on
	PROXY_WSTUNNEL : on
	RATELIMIT      : on
	REFLECTOR      : on
	REMOTEIP       : on
	REQTIMEOUT     : on
	REQUEST        : on
	REWRITE        : on
	SED            : on
	SESSION        : on
	SESSION_COOKIE : on
	SESSION_CRYPTO : on
	SESSION_DBD    : on
	SETENVIF       : on
	SLOTMEM_PLAIN  : on
	SLOTMEM_SHM    : on
	SOCACHE_DBM    : on
	SOCACHE_DC     : off
	SOCACHE_MEMCACHE: on
	SOCACHE_SHMCB  : on
	SPELING        : on
	SSL            : on
	STATUS         : on
	SUBSTITUTE     : on
	SUEXEC         : on
	UNIQUE_ID      : on
	USERDIR        : off
	USERTRACK      : on
	VERSION        : on
	VHOST_ALIAS    : on
	WATCHDOG       : on
	XML2ENC        : on

• PHP 7.2 Options:

	CGI            : on
	CLI            : on
	DEBUG          : off
	DTRACE         : on
	EMBED          : on
	FPM            : on
	IPV6           : on
	LINKTHR        : on
	PHPDBG         : off
	ZTS            : off

Need something more? :)

[icing]

@danel1 could you check release v1.11.3? I think this should solve your issue.

[danel1]

Hey @icing
Thanks for the bump. Sadly it didn't fix the issue for us. :-(
Tried with 2.4.35 and v1.11.3.

[vl-grigorov]

Hi @icing,
I believe I face the same problem.
Tried to describe it here: https://bz.apache.org/bugzilla/show_bug.cgi?id=62955
Reported with apache 2.4.34, but just tried apache-2.4.37 and the issue still persist.

[icing]

Thanks @vl-grigorov, I am currently rather busy with work (projects want to close before X-mas), but will definitely look into this. Can you, on the apache ticket, also include the config part how you enable/embed php? There usually are several possibilities to do so and I am suspecting the method used is relevant to analyze this. Thanks.

[vl-grigorov]

Hello @icing, apache bugzilla started rejecting me with with Error 502 (apache bug system hit a bug?) so I'm not sure I was able to update the ticket. That's why I'll post my notes here too:
Some details on apache/CGI config:

• Server is running on event mpm
• Both PHP and Perl scripts are available via CGI.
• CGI is served via mod_cgid and uses suEXEC.

=====
Some more notes:

• It looks like this php behavior to send only HEAD part if the requested method is HEAD, keeps in mod_php too (as far as I was able to strace a rather busy apache daemon), but I'm unable to test http/2 in this setup due to mpm_prefork/http2 incompatibility.
• In the apache ticket I posted an example perl script that helped me to reproduce the error (again Suexec/CGI), so I believe this is not strictly php-related behavior.
• AddOutputFilterByType workaround works perfectly and looks like a safe (not so) temporary solution.

[felixbuenemann]

Also seeing this issue with Apache 2.4.37 and PHP running via FastCGIExternalServer to php-fpm over unix sockets.

[mkauf]

The bug occurs if the client performs a HEAD request and if the content generator module calls ap_rflush() before generating body data. mod_h2 then inserts the headers and tries to remove body buckets (there are none). This code has a bug, and it removes the headers that it just inserted.

This bugfix works for me:

diff --git a/modules/http2/h2_from_h1.c b/modules/http2/h2_from_h1.c
index d69c53c21b..eaf0c93e28 100644
--- a/modules/http2/h2_from_h1.c
+++ b/modules/http2/h2_from_h1.c
@@ -594,18 +594,20 @@ apr_status_t h2_filter_headers_out(ap_filter_t *f, apr_bucket_brigade *bb)
         }
     }
     
-    if (r->header_only) {
+    if (r->header_only || AP_STATUS_IS_HEADER_ONLY(r)) {
         ap_log_cerror(APLOG_MARK, APLOG_TRACE1, 0, f->c,
-                      "h2_task(%s): header_only, cleanup output brigade", 
+                      "h2_task(%s): headers only, cleanup output brigade", 
                       task->id);
         b = body_bucket? body_bucket : APR_BRIGADE_FIRST(bb);
         while (b != APR_BRIGADE_SENTINEL(bb)) {
             next = APR_BUCKET_NEXT(b);
             if (APR_BUCKET_IS_EOS(b) || AP_BUCKET_IS_EOR(b)) {
                 break;
-            } 
-            APR_BUCKET_REMOVE(b);
-            apr_bucket_destroy(b);
+            }
+            if (!H2_BUCKET_IS_HEADERS(b)) {
+                APR_BUCKET_REMOVE(b);
+                apr_bucket_destroy(b);
+            }
             b = next;
         }
     }

I added AP_STATUS_IS_HEADER_ONLY() to remove body buckets if the HTTP status code implies that the response has no body (204 No Content / 304 Not Modified). I think that's necessary because Apache does it for HTTP 1.x in ap_http_header_filter().

[icing]

@mkauf, finding all my mistakes... :-)

I'll make a version tomorrow with this change and, if verified by the folks here, bring it into the Apache subversion space.

[icing]

I'd appreciate if you could test v1.12.1 where I applied @mkauf 's patch (with modifying AP_STATUS_IS_HEADER_ONLY(r) to AP_STATUS_IS_HEADER_ONLY(r->status).

[felixbuenemann]

Seems to be working fine.

I tested on Ubuntu Trusty with Apache 2.4.37-1+ubuntu14.04.1+deb.sury from Ondrej PPA.

Before updating mod_http2:

* Rebuilt URL to: https://www.louis.info/
*   Trying 134.119.11.167...
* TCP_NODELAY set
* Connected to www.louis.info (134.119.11.167) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f7fd7803c00)
> HEAD / HTTP/2
> Host: www.louis.info
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

After Update to mod_http v1.12.1:

* Rebuilt URL to: https://www.louis.info/
*   Trying 134.119.11.167...
* TCP_NODELAY set
* Connected to www.louis.info (134.119.11.167) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb89e809400)
> HEAD / HTTP/2
> Host: www.louis.info
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Sat, 19 Jan 2019 15:46:13 GMT
< server: Apache/2.4.37 (Ubuntu)
< x-powered-by: PHP/7.0.33-1+ubuntu14.04.1+deb.sury.org+1
< content-language: de
< cache-control: private, no-store
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains
< content-length: 42530
< vary: Accept-Encoding
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< referrer-policy: origin
< content-type: text/html; charset=utf-8
<
* transfer closed with 42530 bytes remaining to read
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (18) transfer closed with 42530 bytes remaining to read

Same Request with --http1.1:

* Rebuilt URL to: https://www.louis.info/
*   Trying 134.119.11.167...
* TCP_NODELAY set
* Connected to www.louis.info (134.119.11.167) port 443 (#0)
* ALPN, offering http/1.1
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
> HEAD / HTTP/1.1
> Host: www.louis.info
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 19 Jan 2019 15:51:47 GMT
< Server: Apache/2.4.37 (Ubuntu)
< X-Powered-By: PHP/7.0.33-1+ubuntu14.04.1+deb.sury.org+1
< Content-Language: de
< Cache-Control: private, no-store
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Upgrade: h2
< Connection: Upgrade
< Content-Length: 42530
< Vary: Accept-Encoding
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Referrer-Policy: origin
< Content-Type: text/html; charset=utf-8
<
* TLSv1.2 (IN), TLS alert, Client hello (1):
* transfer closed with 42530 bytes remaining to read
* stopped the pause stream!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (18) transfer closed with 42530 bytes remaining to read

[icing]

ping, @danel1, I would like to close this after tests by @felixbuenemann verify it works for him.

[towo]

Quick question, I'm getting similar issues when we're doing HEAD on something served via mod_jk using HTTP/2, from the description, I'm guessing that if mod_jk is using ap_rflush, stuff breaks?

For completeness sake:

 curl --http2 -v -I https://$HOST/online/ -k -n
*   Trying $IP...
* TCP_NODELAY set
* Connected to $HOST ($IP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [...]
*  start date: Nov 22 12:38:00 2016 GMT
*  expire date: Nov 20 12:38:00 2026 GMT
*  issuer: [...]
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Server auth using Basic with user 'test'
* Using Stream ID: 1 (easy handle 0x55bbdf8c8e80)
> HEAD /online/ HTTP/2
> Host: $HOST
> Authorization: Basic [...]
> User-Agent: curl/7.63.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
* HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
* stopped the pause stream!
* Connection #0 to host $HOST left intact
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
$ 

This also happens when using valid SSL certificates and no authorization, but we disabled HTTP/2 in the public-facing section since Safari was having issues (either due to this or something else, but economical considerations forced the customer to go for the "safe" approach, until we can or can not verify it's the fault of HTTP/2 handling in Safari), thus I couldn't test it that way right now.

[towo]

Seems to be a likely option: https://github.com/apache/tomcat-connectors/blob/d883c1759b2ad744f594905457abcd38c03edaa6/native/apache-2.0/mod_jk.c#L526

[icing]

@towo can you take v1.12.1 out for a spin and check if it is fixed for you as well?

[towo]

@icing I can try, but does it compile w/ 2.4.23? That's the current environment here (SLES 12), otherwise I'd have to try it with an unpatched build of a recent Apache first just to exclude any additional troubles introduced by the version bump.

[danel1]

@icing Sorry for the delay! Tried right now with v1.12.2 and it works like a charm! Thanks for the fix!

[towo]

I'm having a bit of trouble implementing 1.21.1 to test in this environment here; I'll defer to testing it as soon as I get an upstream package and if the issue still persists, I can always re-open (or rather create a new issue). Thanks!

[icing]

Thanks guys!

Fix has landed in r1852339 in Apache subversion trunk. Will propose for backport to 2.4.x.

[danel1]

Thanks a lot @icing and @mkauf! A backport to 2.4.x would be awesome.

[towo]

FYI, I've received a backport PTF by @SUSE which fixes my problem with chained mod_ajp after mod_http2. Will probably be integrated into one of the next updates for SLES 12.

[icing]

Nice of them. Thanks for letting us know!

[felixbuenemann]

@icing What's the status of the 2.4.x backport?

Looking at the 2.4.x branch, I can see neither a proposed backport in STATUS, nor a merge of r1852339.

[icing]

Correct, thanks for the reminder. I have a bunch of other changes which are to be merged, but I should do this one independently.

[icing]

Proposed in r1854966.

[BloodyIron]

So for those of us getting software from public repos, is this update not available until Apache 2.5.1 becomes available in repos? (main Ubuntu repos, or ondrej)

I'm in an earlier described situation where all iOS devices are failing to load my website, and this sure looks to be the http/2 issue

[icing]

These changes are all part of Apache httpd v2.4.41, released in August 2019.

If/when the distro of your choice picks this up, is beyond my control. You have to take it up with them or chose another one.

[BloodyIron]

But I have 2.4.41 and I still had the issue :/

[icing]

Then then question is what the issue exactly is that you have. And in order to find out, you need to provide some data or log files. For example, if you can reproduce the request that fails, enabled deep logging on the server:

LogLevel http2:trace2

make the failing request and attach the log file here.

[BloodyIron]

Well, the server is now in production so I can't switch that over to a broken state. I was using the Apache2 provided by the onredj PPA btw.

[icing]

I do not understand what it is you want, then. You seem to have the latest fixes that resolve the issue reported here. Maybe it does not work for you or you experience a complete different issue or the issue you saw is somewhere else entirely.

There seems to be nothing I can do for you unless you bring more to the table.

[BloodyIron]

I do not understand what it is you want, then. You seem to have the latest fixes that resolve the issue reported here. Maybe it does not work for you or you experience a complete different issue or the issue you saw is somewhere else entirely.

There seems to be nothing I can do for you unless you bring more to the table.

I understand, I wish I could provide more info. It was a doosie to find the issue was HTTP/2 anyways. If I get more info, I'll post it here, until then, sorry about that.