New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR #167

Closed
danel1 opened this Issue Aug 6, 2018 · 25 comments

Comments

Projects
None yet
6 participants
@danel1
Copy link

danel1 commented Aug 6, 2018

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

This comment has been minimized.

Copy link
Owner

icing commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Author

danel1 commented Aug 10, 2018

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

@icing

This comment has been minimized.

Copy link
Owner

icing commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Author

danel1 commented Aug 10, 2018

Yeah that should be possible.

@icing

This comment has been minimized.

Copy link
Owner

icing commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Author

danel1 commented Aug 13, 2018

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 added a commit that referenced this issue Oct 10, 2018

* Adding defensive code for stream EOS handling, in case the request…
… handler somehow

   missed to signal it the normal way. Should address #167 and #170.
@icing

This comment has been minimized.

Copy link
Owner

icing commented Oct 10, 2018

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

asfgit pushed a commit to apache/httpd that referenced this issue Oct 10, 2018

Stefan Eissing
mod_http2: adding defensive code for stream EOS handling, in case the…
… request handler

     missed to signal it the normal way (eos buckets). Addresses github issues 
     icing/mod_h2#164, icing/mod_h2#167
     and icing/mod_h2#170. 



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1843426 13f79535-47bb-0310-9956-ffa450edef68

asfgit pushed a commit to apache/httpd that referenced this issue Oct 10, 2018

Merge r1843426 from trunk:
mod_http2: adding defensive code for stream EOS handling, in case the request handler
     missed to signal it the normal way (eos buckets). Addresses github issues 
     icing/mod_h2#164, icing/mod_h2#167
     and icing/mod_h2#170. 


Submitted by: icing
Reviewed by: icing, ylavic, jim


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1843468 13f79535-47bb-0310-9956-ffa450edef68
@danel1

This comment has been minimized.

Copy link
Author

danel1 commented Oct 16, 2018

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

This comment has been minimized.

Copy link

vl-grigorov commented Dec 5, 2018

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

This comment has been minimized.

Copy link
Owner

icing commented Dec 6, 2018

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

This comment has been minimized.

Copy link

vl-grigorov commented Dec 6, 2018

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

This comment has been minimized.

Copy link

felixbuenemann commented Jan 12, 2019

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

@mkauf

This comment has been minimized.

Copy link

mkauf commented Jan 17, 2019

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

This comment has been minimized.

Copy link
Owner

icing commented Jan 17, 2019

@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 added a commit that referenced this issue Jan 18, 2019

* Fixed issue where mod_proxy_http2 would trigger an invalid interna…
…l state when retrying requests.

 * applied patch for #167 provided by Michael Kaufmann (@mkauf) about errors on
   HEAD requests (h2 streams not closed cleanly), for example those served by mod_cgid.
@icing

This comment has been minimized.

Copy link
Owner

icing commented Jan 18, 2019

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

This comment has been minimized.

Copy link

felixbuenemann commented Jan 19, 2019

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

This comment has been minimized.

Copy link
Owner

icing commented Jan 21, 2019

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

@towo

This comment has been minimized.

Copy link

towo commented Jan 24, 2019

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.

@icing

This comment has been minimized.

Copy link
Owner

icing commented Jan 24, 2019

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

@towo

This comment has been minimized.

Copy link

towo commented Jan 24, 2019

@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

This comment has been minimized.

Copy link
Author

danel1 commented Jan 28, 2019

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

@towo

This comment has been minimized.

Copy link

towo commented Jan 28, 2019

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!

asfgit pushed a commit to apache/httpd that referenced this issue Jan 28, 2019

Stefan Eissing
*) mod_http2: Configuration directoves H2Push and H2Upgrade can now …
…be specified per

     Location/Directory, e.g. disabling PUSH for a specific set of resources. [Stefan Eissing]

  *) mod_http2: HEAD requests to some module such as mod_cgid caused the stream to
     terminate improperly and cause a HTTP/2 PROTOCOL_ERROR. 
     Fixes <icing/mod_h2#167>. [Michael Kaufmann]



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1852339 13f79535-47bb-0310-9956-ffa450edef68
@icing

This comment has been minimized.

Copy link
Owner

icing commented Jan 28, 2019

Thanks guys!

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

@icing icing closed this Jan 28, 2019

@danel1

This comment has been minimized.

Copy link
Author

danel1 commented Jan 28, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment