rangoy

Thank you very much for the update!

One more update to the update. Even though my hack worked, reading jquery documentation I suspect I found the root cause of the issue.
The accepts: in obj.getAjaxSettings is not actually necessary, because it depends on the dataType. So, just deleting/commenting out the line “accepts:'html'” (manager.js line 499) actually fixes the issue, because the Accept header will be correct by datatype default.
Alternatively, if the accepts for some reason should be explicit, it would need to be specified as follows, which would give the same result as deleting the line:

accepts: {
   'html': 'text/html'
    },
dataType: 'html',

An update:

After hours of investigation far outside my competence, I was able to find a workaround for this, and perhaps it could help others.

Using Postman, i tried to find out excactly what was treated different by the two servers, and finally found that the difference was in the server side handling of the Request Header “accept: undefined”.

Checking the plugin source code, I found that the ajax request is set up in obj.getAjaxSettings with accepts: ‘html’, but that this does not affect the headers actually sent by the XHR request. In order to set the header explicitly, I added a line to obj.ajaxBeforeSend telling it to set the request header like jqXHR.setRequestHeader(“Accept”, “*/*”) or jqXHR.setRequestHeader(“Accept”, “text/html”) – the main thing seems to be that the slash needs to be present. So, in context, ?I amended /src/resources/js/views/manager.js (line 531) like this:

obj.ajaxBeforeSend = function( jqXHR, settings ) {
               var $container = this;
               var $loader = $container.find( obj.selectors.loader );

               jqXHR.setRequestHeader("Accept", "*/*");
               $container.trigger( 'beforeAjaxBeforeSend.tribeEvents', [ jqXHR, settings ] );

               if ( $loader.length ) {
                       $loader.removeClass( obj.selectors.hiddenElement.className() );
                       var $loaderText = $loader.find( obj.selectors.loaderText );
                       $loaderText.text( $loaderText.text() );
               }
               $container.attr( 'aria-busy', 'true' );

               $container.trigger( 'afterAjaxBeforeSend.tribeEvents', [ jqXHR, settings ] );
       };

Voilà, it works! So, I guess there must be some kind of bug here, either in the plugin or in jquery itself, that is only triggered by some server setups being stricter about the format of the accept header. I also noticed that this code in manager.js (line 499 emphasized):

obj.getAjaxSettings = function( $container ) {
 var ajaxSettings = {
  url: $container.data( 'view-rest-url' ),
  accepts: 'html',
  dataType: 'html',
  method: $container.data( 'view-rest-method' ) || 'POST',
  'async': true, // async is keyword
  beforeSend: obj.ajaxBeforeSend,
  complete: obj.ajaxComplete,
  success: obj.ajaxSuccess,
  error: obj.ajaxError,
  context: $container,
};

… counterintuitively does nothing to set the actual header. For reference, I am running the newest Chrome 110.0.5481.100 on Linux, but tested also in modern Edge and Konqueror, with the bug consistent in both and also being reported by users on other platforms. The server reports Server API LiteSpeed V8.0.1 Cloudlinux 1.3.

So with this line added, it works for me, for now. But any feedfack is welcome as to whether my fix is the correct one. Thanks in advance!