AJAX HTTP2 error

  • Resolved hagiz

    (@hagiz)


    1 month, 3 weeks ago

    Good morning!

    I’ve just installed the latest Loco Translate plugin and started following my theme’s (sapa) instructions to setup multilingual site. I faced a strange error that some ajax request are not delivered correctly. In admin panel I see an error “Blank response from server”. I did an investigation and spotted in devtools that request to admin-ajax.php fails due to net::ERR_HTTP2_PROTOCOL_ERROR. It looks like obvious server configuration issue, but other request to the same endpoint works fine, like of type action: heartbeat.
    I’ve triggered two ajax actions related to loco translate, and both failed:

    # Action 1 payload
    path: themes/sapa/languages/sapa.pot
    auth: update
    action: loco_json
    route: fsConnect
    loco-nonce: a80b865b95

    # Action 2 payload (clicked "sync" button in loco's theme view"
    interval: 120
    _nonce: c8dde9d457
    action: heartbeat
    screen_id: loco-translate_page_loco-theme
    has_focus: false

    I hasn’t been able to attach an image here, so there is an external link to screenshot from my admin panel: https://i.imgur.com/wzc3euT.png

    What is interesting, sometimes in devtools, I can see some data in response tab, but nothing in preview tab. That suggest that php sends some data, but it’s rejected because some HTTP headers discrepancy or something. I enabled debuging mode in wordpres (WP_DEBUG), but didn’t find any new, useful information.

    My plugin version is 2.7.1. I am using the latest chrome (the same behavior on Edge browser), the webpage is hosted on OVH shared hosting, so I believe that server settings should be fine, as I can’t change them anyway. Please let me know if this is a known bug or an issue on my side. That error prevent me from using the plugin, because the admin panel is totally broken.
    Sorry for reporting an HTTP error. I read in docs that You don’t provide support for that kind of issues, but I believe it might be related to some bug rather configuration. I believe it might be useful to pay Your attention to this.

    Kind regards!
    Grzegorz

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Tim W

    (@timwhitlock)

    but it’s rejected because some HTTP headers discrepancy or something

    It is probable that headers are the problem.

    I can only make guesses, but based on things I’ve seen previously: Any unwanted output from PHP will likely produce an incorrect content-length header. Loco Translate tries to buffer junk output and delete it, but there are situations where that may be impossible.

    Unwanted output is often PHP errors, but could be as simple as a typo, or accidental space. You need to see the output that is causing the issue, or – if there is none – eliminate that as a cause. This won’t be easy, but if there is an error it will still be there if HTTP2 is disabled. So I’d suggest doing that for visibility as a first course of action. If there is no junk output under HTTPv1, you can move on to other possible cases.

    Other possible causes I’ve heard of include output compression quirks. Check that section of the FAQ.

    Beyond this, my guesses are as good as yours.

    —

    If you’re not able to disable HTTP2, you could check for junk output with some code like this, which will run when Loco Translate tries to exit with well-formed JSON.

    add_action('loco_admin_shutdown', function(){
      if( loco_doing_ajax() && headers_sent($f,$n) ){
        error_log( sprintf('headers_sent() => %s#%u)',$f,$n) );
      }
    } );

    Thread Starter hagiz

    (@hagiz)

    @timwhitlock Thanks for reply!
    Before deep dive into investigation, I tried a low-hanging fruit, so in my case – disable WP Rocket plugin, which optimizes assets delivery, including some minification and compressing of JS, CSS, images, etc.
    I didn’t expect I find it that quick. Disabling the plugin works, no HTTP errors anymore in admin panel. So to finally get rid of problem I have two solutions – setup Loco translate with disabled WP Rocket, and then enable it “for production”, or find a way to setup an exception for that endpoint/request in Rocket.

    So, if someone find simillar issue I had – in my case, a 3rd party plugin was the source of problem.

    Plugin Author Tim W

    (@timwhitlock)

    Thanks for the follow up. I’ve seen WP Rocket come up a number of times as a problem for my plugin.

    I’ll have a go myself to see if I can reproduce what it’s doing to my Ajax requests. I suspect it’s some kind of compression to the JSON data that doesn’t modify the content-length header, but I’ll see what I can see.

    Plugin Author Tim W

    (@timwhitlock)

    Just discovered WP Rocket is a paid plugin. Sorry, I can’t help with it.

    If you’re able to find out what it’s doing, I’m interested to know. But unless there’s a free version I won’t be able to reproduce.

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.