ERR_SPDY_PROTOCOL_ERROR on wp-admin multisite + cloudflare

[Raul P.]

Hi there,

I have a strange issue, where I install everything and it works fine without cloudflare... but stops working with cloudflare on the login page only.

• WP 5.1.1 multisite, with subdirectories.
• nginx version: nginx/1.15.12 with brotli and ngx_cache_purge (also tried the default ubuntu package)
• ubuntu 18.04 (on digital ocean)
• running PHP 7.2.17-1+ubuntu18.04.1+deb.sury.org+3
• disabled all plugins, except nginx helper
• Google Chrome Version 73.0.3683.103 and tested on other devices as well

Headers on wp-login.php, when not using cloudflare:

HTTP/2 200
server: nginx
date: Sun, 28 Apr 2019 18:28:33 GMT
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP+Cookie+check; path=/; secure
x-frame-options: SAMEORIGIN
x-cache: BYPASS

Same, but with cloudflare:

HTTP/2 200
date: Sun, 28 Apr 2019 18:29:52 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d23802e7392b0411bfcaa67dbc95387011556476192; expires=Mon, 27-Apr-20 18:29:52 GMT; path=/; domain=.domain.com; HttpOnly
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP+Cookie+check; path=/; secure
x-frame-options: SAMEORIGIN
vary: Accept-Encoding
x-cache: BYPASS
strict-transport-security: max-age=0; preload
x-content-type-options: nosniff
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4ceb1aab6c75c351-SIN

Browser console:
http://prntscr.com/nhzhhu

Some curl info when on cloudflare:

curl -vso /dev/null https://domain.com/wp-login.php
*   Trying 104.25.60.6...
* TCP_NODELAY set
* Connected to domain.com (104.25.60.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* (304) (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [15 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [3857 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* (304) (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Certificate Status (22):
} [1 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=ssl370775.cloudflaressl.com
*  start date: Apr  8 00:00:00 2019 GMT
*  expire date: Oct 15 23:59:59 2019 GMT
*  subjectAltName: host "domain.com" matched cert's "domain.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
*  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
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* Using Stream ID: 1 (easy handle 0x5646b5808530)
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
> GET /wp-login.php HTTP/2
> Host: domain.com
> User-Agent: curl/7.58.0
> Accept: */*
>
{ [5 bytes data]
* (304) (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* (304) (IN), TLS handshake, Newsession Ticket (4):
{ [238 bytes data]
* (304) (IN), TLS handshake, Newsession Ticket (4):
{ [238 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
< HTTP/2 200
< date: Sun, 28 Apr 2019 18:32:38 GMT
< content-type: text/html; charset=UTF-8
< set-cookie: __cfduid=deecc2c9a583dfe41eee38ea337af45cb1556476357; expires=Mon, 27-Apr-20 18:32:37 GMT; path=/; domain=.domain.com; HttpOnly
< expires: Wed, 11 Jan 1984 05:00:00 GMT
< cache-control: no-cache, must-revalidate, max-age=0
< set-cookie: wordpress_test_cookie=WP+Cookie+check; path=/; secure
< x-frame-options: SAMEORIGIN
< vary: Accept-Encoding
< x-cache: BYPASS
< strict-transport-security: max-age=0; preload
< x-content-type-options: nosniff
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4ceb1eb51c97cbda-SIN
<
{ [920 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
* Connection #0 to host domain.com left intact

This only happens on wp-admin or wp-login.php and the rest of the site works fine.
As soon as I rename the nginx-helper plugin (2.0.3), it works fine.
Any idea of what this is, or is there any way to disable the plugin completely on wp-login.php ?

Also from what I can see, I downgraded nginx-helper all the way to 1.6.6 and it finally worked, so it seems it was something introduced on 1.6.7 onwards, that is causing this issue.

[Raul P.]

OK... so, I managed to track it down to the "Enable Nginx Timestamp in HTML" option.

It happens on nginx-helper/admin/class-nginx-helper-admin.php:459 on the echo wp_kses( $timestamps, array() ); which comes from the "Enable Nginx Timestamp in HTML" option.

I'm dealing with a client site that uses a theme from AIT Themes (Zox News) and it hasn't been updated in a while. It's possible, they have coded something into it that conflicts with the output... but regardless, I think nginx-helper needs some fix, not to add time stamps in html, on login or wp-admin pages.

Maybe check for wp_login_url and do some checks for the url... here are some ideas:
https://codex.wordpress.org/Function_Reference/wp_login_url https://wordpress.stackexchange.com/questions/12863/check-if-wp-login-is-current-page

[Chandra Patel]

Hello @peixotorms

First, my apologies for late reply and for the issue you have faced. I agree that Nginx timestamp should not add on WP login page.

I have created PR #220 to fix it and we will release this fix in next version.

Thanks,