De 404-fout van Cloudflare Workers oplossen na een succesvolle implementatie

Problemen met de stagingomgeving oplossen met Cloudflare Workers

Een essentiële fase in het ontwikkelproces is het opzetten van een staging-omgeving, zodat updates goed kunnen worden getest voordat ze live gaan. In dit geval zorgden Cloudflare Workers ervoor dat de primaire website in ontwikkeling goed functioneerde.

Na het klonen van de bestaande Git-repository en het verbinden met de staging-omgeving via Cloudflare Workers & Pages, leek alles goed te werken. De logboeken gaven aan dat de implementatie succesvol was, wat doorgaans zou duiden op het maken van een live exemplaar.

Maar toen de ontwikkelaar toegang probeerde te krijgen tot het opgegeven Cloudflare-adres, verscheen er een 404-foutmelding, waardoor hij niet zeker wist wat er mis ging. Het kan vervelend zijn om met dit soort problemen om te gaan, vooral als men denkt dat de server direct na implementatie live moet zijn.

Het is onduidelijk of er een tweede server nodig is of dat er nog iets moet gebeuren om de nieuwe repository volledig te activeren. In dit artikel zullen we kijken naar de oorzaken van dit 404-probleem en hoe u de Cloudflare Workers-server correct kunt instellen voor de staging-omgeving.

Hoe Cloudflare-werknemers en -scripts omgaan met 404-fouten

Het eerste script in het gegeven voorbeeld laat zien hoe u het moet gebruiken JavaScript om een ​​404-fout op de frontend af te handelen. Het script maakt gebruik van de venster.onload gebeurtenis om te wachten tot de pagina volledig is geladen. De pagina maakt een ophalen verzoek om te zien of de bron beschikbaar is nadat deze is geladen. De gebruiker wordt naar een aangepaste foutpagina gestuurd als de bron een 404-fout retourneert. Omdat er geen backend-betrokkenheid nodig is, is deze techniek vooral handig voor het beheren van fouten rechtstreeks in de browser van de gebruiker en het bieden van een reserve voor ontbrekende pagina's of bronnen.

In het tweede voorbeeld beheert het script verzoeken met behulp van a Cloudflare-werknemer terwijl het naar de backend gaat. De werknemer maakt gebruik van de addEventListener methode om naar gebeurtenissen te luisteren en ophaalverzoeken te onderscheppen wanneer deze worden gedaan. In het geval dat er een 404-fout optreedt omdat de opgevraagde pagina niet bestaat, zal de medewerker dynamisch een aangepaste foutpagina aanbieden. Deze strategie werkt goed voor het beheren van serverantwoorden en biedt een meer aanpasbare en veilige manier om met fouten om te gaan, vooral bij het werken met verschillende contexten, zoals productie en staging of dynamische inhoud.

Om ervoor te zorgen dat frontend- en backend-scripts correct worden geïmplementeerd en werken, worden in het derde voorbeeld unit-tests geïntroduceerd. Het voert geautomatiseerde tests uit om te zien of de Cloudflare Pages-implementatie de juiste HTTP-statuscodes retourneert met behulp van Knooppunt.js en een testraamwerk zoals Mocha. Tests voor de hoofdpagina (die een 200-status aannemen) en tests voor een niet-bestaande pagina (die een 404-status verwachten) zijn beide opgenomen in de testsuite. Deze tests zorgen ervoor dat alles volgens plan wordt ingezet en dat eventuele kapotte pagina's of links resulteren in de juiste reactie.

Bovendien is het gebruik van de tests van beweren commands garandeert dat eventuele verschillen in de responsstatuscodes meteen worden gedetecteerd. In continue integratie- en implementatiepijplijnen (CI/CD), waar het garanderen van implementatiegedrag cruciaal is om downtime of verbroken verbindingen te voorkomen, zijn tests onmisbaar. Alles bij elkaar genomen biedt de samensmelting van frontend-omleiding, backend-foutafhandeling en unit-tests een grondige aanpak om de naadloze werking van uw Cloudflare Workers-implementatie te garanderen, zelfs in het geval van ontbrekende bronnen of aangepaste omstandigheden zoals een staging-server.

// Frontend JavaScript for handling redirection
// This script checks if a resource is available on the Cloudflare page
// If not, it redirects to a fallback page
window.onload = function () {
  fetch(window.location.href)
    .then(response => {
      if (response.status === 404) {
        window.location.href = '/404.html';  // Redirect to custom 404 page
      }
    })
    .catch(error => {
      console.error('Error fetching the page:', error);
      window.location.href = '/error.html';  // Redirect to error page
    });
};

// Cloudflare Worker script for managing 404 errors
// The script checks if the requested path exists, and if not, returns a custom 404 page
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
  try {
    const response = await fetch(request);
    if (response.status === 404) {
      return new Response('Custom 404 Page', { status: 404 });
    }
    return response;
  } catch (error) {
    return new Response('Error occurred: ' + error.message, { status: 500 });
  }
}

// Example unit test for deployment verification
// Using JavaScript to ensure that Cloudflare Pages return the correct response
const assert = require('assert');
const fetch = require('node-fetch');
describe('Cloudflare Deployment Test', function() {
  it('should return 200 for the main page', async function() {
    const response = await fetch('https://your-domain.pages.dev');
    assert.equal(response.status, 200);
  });
  it('should return 404 for non-existent page', async function() {
    const response = await fetch('https://your-domain.pages.dev/unknown');
    assert.equal(response.status, 404);
  });
});

Inzicht in de staging-omgeving van Cloudflare-werknemers

Voor ontwikkelingsdoeleinden kan het installeren van een testomgeving cruciaal zijn bij het werken met Cloudflare-werknemers. Ontwikkelaars kunnen hun applicaties testen in een testomgeving voordat ze op de productieserver worden geïmplementeerd. Om problemen zoals de aangegeven 404-fout te voorkomen, moet deze omgeving bij de eerste installatie goed zijn geconfigureerd. Ontwikkelaars zijn vaak van mening dat het enige wat nodig is om een ​​live server te lanceren het klonen van een GitHub-repository is en deze verbindt met Cloudflare Pages. Hoewel Cloudflare automatisch statische sites implementeert, kunnen er problemen optreden als de routeringsconfiguratie van de werknemer niet correct is ingesteld.

Een 404-fout betekent vaak dat het verzoek niet goed wordt onderschept door de Werknemer. Aangepaste routeringsregels zijn nodig voor Cloudflare Workers om te garanderen dat verzoeken naar de juiste plaats worden verzonden. Zelfs nadat de site is gelanceerd, kunnen verzoeken voor sommige pagina's een 404-fout retourneren als deze routes niet zijn ingesteld. Het is ook van cruciaal belang ervoor te zorgen dat het Worker-script is verbonden met het stagingdomein. Deze fouten kunnen tijdens de ontwikkeling worden verminderd door een goed georganiseerde werker in te zetten en de routes te valideren.

Zorg ervoor dat de Werker nog steeds verbonden is met uw staging-domein is een volgende cruciale stap. Het kan voorkomen dat de Werknemer zich tijdens de implementatie niet automatisch aan de nieuwe omgeving bindt, vooral als er meerdere omgevingen zijn (zoals productie en staging). Om de Worker handmatig aan de specifieke omgeving te koppelen en ervoor te zorgen dat verzoeken op de juiste manier worden verwerkt, kunnen ontwikkelaars het dashboard van Cloudflare gebruiken. Om de staging- en productieomgevingen soepel en foutloos te laten verlopen, is deze stap noodzakelijk.