Worker request shows 200 and 500 on reload

Developers Workers
1

Every odd request I get a Error 1101 “Rendering error”… I tried a lot of different versions but it seems I cant get rid of it… this only happens when the client browser has caching on (default), via the web console with caching off or via holding shift and reloading it works every time. Somehow the second cached request breaks? I tried clearing the browsers cache and used different browsers including mobile and its the same outcome. Every second request = error.

Here is the full code to modify the content:

addEventListener('fetch', event => {
  event.respondWith(handle(event.request));
});

async function handle( request ) {
  const response = await fetch( request );
  if( response.headers.get( 'content-type' ).indexOf( 'text/html' ) !== -1 ) {
    try {
      const body = await response.text();
      return new Response(
        rewritebody( body, request ),
        response
      );
    }
    catch( e ) {
      return response;
    }
  }
  else {
    return response;
  }
}

function rewritebody( body, r ) {
  if( body.indexOf( '§REF:http' ) !== -1 ) {
    const match = body.match( /§REF:([^§]+)§/ );
    if( typeof match[1] !== 'undefined' ) {
      const url = match[1].replace( /\{r\}/, encodeURIComponent( r.url ) );
      body = body.replace( /<\!--.+?REF\:http[^>]+?-->/, '<!-- url:'+url+' -->' );
    }
  }
  return body;
}
3

Got the same problem. My worker was fetching a file from S3 and modifying it.
I got it to stop when I by accident cleaned some of the response headers.
response.headers.delete(‘ETag’);
response.headers.delete(‘Server’);
response.headers.delete(‘Last-Modified’);
response.headers.delete(‘x-amz-id-2’);
response.headers.delete(‘x-amz-request-id’);
response.headers.delete(‘Cookie’);

I’m pretty sure the ETag was the culprit. Modifying the document in my worker probably messed up the ETag hash.

If the hashes don’t match, it means that the document has been edited in-between and a 412 Precondition Failed error is thrown.

4

do you do a fetch to a public object S3 or signed?

5

public

6

Hi @awsm, sorry for my late reply.

Flapping errors like this often indicate that the script is not handling 304 responses correctly. 304 responses are generated by origins in response to conditional requests, which are generated by browsers’ HTTP caches, which is why you are only seeing this when browsers have caching enabled. Such responses have a couple idiosyncrasies which are a common source of errors:

  • They have no Content-Type header.
  • They have no body.

To debug a problem like this, I’d recommend wrapping the entire handle(request) function body in a try-catch, as described in the Debugging Tips section of our documentation, then report any caught error messages in the response body or a response header. In this particular case, I suspect you will find that it is this expression that is causing problems, due to the lack of a Content-Type header on 304 responses:

response.headers.get( 'content-type' ).indexOf( 'text/html' )

It’s usually sufficient to handle 304 responses by wrapping the main logic of your worker in an if (response.status === 200) block. If you know that you must also handle certain other non-200 responses, you might instead consider if (response.body !== null).

In either case, I’d also recommend checking for the presence of the Content-Type header (e.g. with response.headers.has('content-type') before attempting to read it.

Harris