Posted by Patrick R on Mon, Jan 01, 2024 - 7:02am --- Updated: Mar 28 '24 - 7:41am

Hello and happy new year to all,

I recently upgraded a Drupal 7 site to Backdrop (version 1.26.3) following the Upgrading from Drupal guide.

The old D7 site and the final Backdrop site are in the same shared hosting environment (OVH) with Apache/PHP 8.1 and a Let's Encrypt SSL certificate.

In HTTPS, the D7 site works as expected in:

  • Firefox (Windows and Linux)
  • Google Chrome (Windows) and Chromium (Linux)
  • MS Edge

The Backdrop site however only works in Firefox.
In Chrome and Edge, I get a blank page and the following error in the browser console: 

net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK)

(Note: in HTTP the Backdrop site works as expected in all browsers)

The error occurs on all pages of the site.

I tried with no success:

  • Accessing the site from another location (to rule out any problem with my internet connection)
  • Visiting the site in incognito mode
  • Replacing my custom theme with Bartik
  • Disabling contrib and custom modules
  • Regenerating the SSL certificate
  • Enabling/disabling aggregation of CSS and JS files
  • Clearing all caches (via the UI and with bee cc all)
  • Clearing the browser cache, history and cookies (in some rare cases the pages loaded correctly just after that but the next request triggered the  error again)

Finding:
The Backdrop site works in Chrome when I comment out the following line in the function backdrop_set_length_headers (file core/includes/bootstrap.inc): 

backdrop_add_http_header('Content-Length', $content_length);

 

Has anyone experienced this situation?

Any suggestions would be greatly appreciated.

EDIT:
For some reason, the site works for visitors in all browsers when I select both "Cache pages for anonymous users" and "Compress cached pages" on the Performance page.

Even with those two options enabled, I still cannot access the admin pages in Chrome and Edge though  (I get the ERR_HTTP2_PROTOCOL_ERROR just after submitting my credentials).

EDIT 2 (SOLVED):
For some reason, the issue disappeared after I changed the PHP runtime environment from PHP-FPM to PHP CGI on my shared host (OVH) and this seems to work whether pages are cached or not.
Documentation: https://help.ovhcloud.com/csm/en-web-hosting-change-php-version?id=kb_ar...

 

 

 

 

 

Accepted answer

For some reason, the issue disappeared after I changed the PHP runtime environment from PHP-FPM to PHP CGI on my shared host (OVH) and this seems to work whether pages are cached or not.

 

Most helpful answers

The preview comment links to

Preview comment flagged as spam as it contains a link to the website of an online game.

Patrick, you may be on to

Patrick, you may be on to something here. backdrop_set_length_headers() is called twice in a normal admin page request: once to retrieve the page, and then a second time when the browser does an ajax request to get the admin bar. Each time, the page length is different (the second time is longer, as it contains the whole page and the admin bar js and stuff, which are cherry picked by js code to render the bar on the page). Maybe this is somehow confusing your server (because of a setting?). It'd be interesting to see if the server is indeed sending the first request right away, or perhaps somehow caching it until the second request is finished (I'm "spitballing" here). 

I know very little about servers, but I do know the number of configurations is large and may end up with unexpected results. Also different servers may seem the same but act subtly differently (we had a big issue with cached pages and Litespeed servers a year ago, that took quite a bit to fix). So, perhaps, you are on to something...

 

[EDIT]: but then that doesn't explain why an anonymous request (which doesn't request an admin bar) would have issue...

Comments

Mon, Jan 01, 2024 - 7:54am by argiepiano

Have you tried opening the site in an incognito window? 

Any chance you can share the url, perhaps privately via the backdrop ma zulip channel? 

I'm no expert on this, and you may have already read articles like this, 

https://kinsta.com/knowledgebase/err_http2_protocol_error/

That article makes it sound like the problem may be on the browser side... So sharing the url would allow others to test.

 

Mon, Jan 01, 2024 - 9:37am by Patrick R

Thank you for the quick reply.

Sorry, I should have mentioned I had tried in Incognito mode with the same result.

I have updated my OP with the URLs.

I read the article you mentioned but indeed it only suggests client-side fixes.

This conversation on Stack Overflow points to possible server-side causes (invalid certificate, lack of disk space, double-compression,...). However since the D7 and Backdrop sites are on the same server and the former works as expected, I assume there is a problem with my Backdrop installation.

Mon, Jan 01, 2024 - 9:58am by yorkshirepudding

Hi @PatrickR

I can see the same issue you are.  I suspect (but am not certain) this could be to do with the .htaccess file in the web root.

Perhaps take a look at the .htaccess in the latest release:

https://github.com/backdrop/backdrop/blob/1.26.3/.htaccess

And see if yours is missing some key aspects.

You could start with the core one and use the examples to recreate what you need.

Mon, Jan 01, 2024 - 10:16am by Patrick R

Thanks for your reply @yorkshirepudding.

I have replaced the .htaccess with the one from the latest release but the problem remains.

Mon, Jan 01, 2024 - 11:22am by argiepiano

Patrick, I'm looking at the BD page on Firefox. Although it's loading, I'm seeing issues with the request. The page takes a very long time to load when I clear browser caches and cookies. It's also showing "NS_ERROR_NET_PARTIAL_TRANSFER" after it loads:

So, there is a general problem with either the server or the setup. 

  • Are you seeing this issues when you are logged in as admin as well? 
  • Can you try turning off "Use background fetch for cached pages" on admin/config/development/performance
  • Tell us a bit about the page we are seeing. How did you accomplish it? Did you hard code this into a template? Did you use a layout page and set it as front page?
  • Is this happening only on this server? Do you have a dev version of the site locally that you can test?

 

One more observation: if I request your site through an insecure request (with http://) I don't see any issues both in Chrome or Firefox.  This may mean a problem with the certificate? Have you tried removing the Lets Encrypt certificate and reinstalling it? 

Tue, Jan 02, 2024 - 3:39am by Patrick R


Are you seeing this issues when you are logged in as admin as well?

I see "NS_ERROR_NET_PARTIAL_TRANSFER" when I'm logged in as well.
The response times (both logged in and anonymous) look normal on my side though:

Can you try turning off "Use background fetch for cached pages" on admin/config/development/performance

Strangely I don't have that option. Here is what my Performance page looks like:

I have the administrator role, so I assume it is not a question of permissions.


Tell us a bit about the page we are seeing. How did you accomplish it? Did you hard code this into a template? Did you use a layout page and set it as front page?

The content of the page is returned as a render array by a callback function defined in a custom module.
Here is a print_r of the array before the function returns:

The callback function is invoked via a path (menu item) which is set as home page on /admin/config/system/site-information.

The content is displayed by a custom page.tpl.php (part of my custom theme):

I created a custom layout (under /layouts) based on a copy of Boxton (/core/layouts/boxton).
I then selected that layout as default layout and removed all its blocks except "Main page content":

 

Is this happening only on this server? Do you have a dev version of the site locally that you can test?

I have a local version of the site on my computer but I can only test in HTTP for the moment (and the issues only occur in HTTPS). 
I will try to enable HTTPS in that local environment to see if I can reproduce the issues there.

 Have you tried removing the Lets Encrypt certificate and reinstalling it?

I have tried that several times but with no luck.

 

Tue, Jan 02, 2024 - 9:42am by argiepiano

Can you check the file settings.php to see if you have set up a value for $base_url? Typically a value is not needed for that variable. Sometimes setting this value to http://example.com when the connection is supposed to be https://example.com can create issues.

Tue, Jan 02, 2024 - 10:25am by Patrick R

Thanks @argiepiano.  I have checked and $base_url was not set.

I have also tried to set it up to the (https://) URL of my Backdrop installation but that didn't change anything.

Wed, Jan 03, 2024 - 6:55am by argiepiano

OK, I'm really stumped. I have done D7 upgrades to Backdrop, and I'm using shared hosting with ssl, and have never experienced this problem. Your Layout looks correct.

The next things I'd try:

1. Contact tech support of your shared hosting and explain the problem. Tell them about the browser console error. You'd be surprised - sometimes these problems are due to server configurations

2. Make an effort to set up your local environment to use ssl, so that you can debug your site more easily. Do you use MAMP? 

 

Fri, Jan 05, 2024 - 7:37am by Patrick R

Thank you argiepiano.

Make an effort to set up your local environment to use ssl, so that you can debug your site more easily. Do you use MAMP? 

I don't use MAMP but the Apache and MySQL included in my Linux distribution.

I manage to set up HTTPS in my local environment but still need to enable HTTP/2 in order to mimic the live server (the issue is not present in HTTP(S)/1.1).

In the meantime, I have found that the site works in Chrome when I comment out the following line in the function backdrop_set_length_headers (file core/includes/bootstrap.inc):

backdrop_add_http_header('Content-Length', $content_length);

Obviously not a solution but maybe a hint (?)  I have updated the OP with that information.

Referring to your comment of January 1: do you have any idea why I don't see the option "Use background fetch for cached pages" on the Performance page?:

I have the administrator role so I assume it's not a question of permissions.

 

 

Sat, Jan 06, 2024 - 6:04am by argiepiano

In the meantime, I have found that the site works in Chrome when I comment out the following line in the function backdrop_set_length_headers (file core/includes/bootstrap.inc):

Interesting! This may help troubleshoot the problem. 

The option "Use background fetch for cached pages" only appears if you enable "Cache pages for anonymous users". Try playing around with those options...

Sat, Jan 06, 2024 - 6:23am by argiepiano

Patrick, you may be on to something here. backdrop_set_length_headers() is called twice in a normal admin page request: once to retrieve the page, and then a second time when the browser does an ajax request to get the admin bar. Each time, the page length is different (the second time is longer, as it contains the whole page and the admin bar js and stuff, which are cherry picked by js code to render the bar on the page). Maybe this is somehow confusing your server (because of a setting?). It'd be interesting to see if the server is indeed sending the first request right away, or perhaps somehow caching it until the second request is finished (I'm "spitballing" here). 

I know very little about servers, but I do know the number of configurations is large and may end up with unexpected results. Also different servers may seem the same but act subtly differently (we had a big issue with cached pages and Litespeed servers a year ago, that took quite a bit to fix). So, perhaps, you are on to something...

 

[EDIT]: but then that doesn't explain why an anonymous request (which doesn't request an admin bar) would have issue...

Sun, Jan 07, 2024 - 1:27am by Patrick R

The option "Use background fetch for cached pages" only appears if you enable
"Cache pages for anonymous users"

Silly me, I didn't even try that!

Interestingly, when I select the options "Cache pages for anonymous users" AND "Compress cached pages", the error disappears and the site works as expected in Chrome and Edge (whether "Use background fetch for cached pages" is selected or not).

If I only select "Cache pages for anonymous users" (without the compress option), the error occurs.

The cache + compress combination also fixes another issue which I hadn't mentioned before, namely, the admin bar only appears on the "Status report" page (/admin/reports/status) while on other admin pages, it only appears just after clearing caches and disappears on the next request.
My understanding of the caching system is very limited but I find it strange that options related to anonymous requests interfere with the admin UI...

I'll see if I can reproduce that in my local environment (I am still trying to enable HTTP2, which turns out to be trickier than I expected).

Thank you for pointing me in the right direction!

 

Sat, Jan 13, 2024 - 6:44am by Patrick R

Hi @argiepiano

I managed to enable HTTP2 in my local environment and I'm not able to reproduce the issue (the site works in all browsers, whether I cache and compress the pages or not).

So like you said, some setting on the live server must be causing the issue.

Thanks a lot for your help.

 

Sat, Feb 10, 2024 - 10:26am by Patrick R

For some reason, the issue disappeared after I changed the PHP runtime environment from PHP-FPM to PHP CGI on my shared host (OVH) and this seems to work whether pages are cached or not.

 

Fri, Mar 29, 2024 - 4:52am by Patrick R

Preview comment flagged as spam as it contains a link to the website of an online game.

Wed, Apr 10, 2024 - 2:18am by yorkshirepudding

Thanks Patrick. Deleted.