Mozilla experimenteert met vervangen 404-pagina's door Wayback Machine-varianten

Mozilla test een functie in Firefox via het Test Pilot-programma waardoor gebruikers bij het verschijnen van een 404-pagina automatisch een link naar de historische pagina in de Wayback Machine van het Internet Archive krijgen.

De functie heet 404 No More en zou ervoor moeten zorgen dat dode links naar pagina's die ooit bestonden op nog bestaande servers, makkelijker ingezien kunnen worden. Er verschijnt alleen een link naar een Wayback Machine-snapshot als die werkelijk bestaat.

Om een gecachete versie van een site op te kunnen vragen, stuurt de browser de url van een 404-errorpagina naar Archive.org. Mozilla houdt bij hoeveel mensen de add-on geïnstalleerd hebben, hoe vaak 404-pagina's tegengekomen worden waar geen match voor is bij Archive.org en hoe vaak er doorgeklikt wordt naar een Archive.org-pagina. Al die data is aan de serverkant bij te houden. Voor het bijhouden van het totale aantal 404-pagina's dat een gebruiker in een sessie tegenkomt, moet eerst nog bekeken worden hoe dat zit met de privacy van gebruikers, schrijft Mozilla op de GitHub-pagina van het project.

Het Test Pilot-programma bestaat sinds mei dit jaar en is een add-on die toegevoegd kan worden aan de browser. De gebruiker krijgt dan een nieuwe knop in de werkbalk van waaruit experimentele features benaderd kunnen worden. Experimentele functies worden mogelijk in de toekomst aan nieuwe releases van Firefox toegevoegd als ze goed bevallen.

Het blijkt niet eenvoudig pagina's te vinden die ook daadwerkelijk een gecachete versie hadden, maar via een bericht uit het verre verleden op Tweakers was een juiste doorverwijzing tevoorschijn te toveren:

Reacties (63)

[velenski]

slechte zaak.
als ik pagina's verwijder of hernoem wil ik niet dat mensen een oude pagina geserveerd krijgen.

sysadmins zouden dit zelf moeten bepalen en niet Mozilla.

[ThomasG]

Je kunt gewoon aangeven dat je niet wilt dat zoekmachines en/of sites als The Wayback machine jouw pagina cachen/opslaan, middels een robots.txt. Daarbij, als de web-site goed in elkaar zit zorg je er voor dat pagina's welke zijn hernoemt een 301 Permanent status krijgen.

[bartje]

daar ben ik het niet mee eens.
kan ik dan ook aangeven dat de waybackmachine mijn data uit het verleden verwijdert?
een 301 is goed als ik een nieuwe pagina heb. maar wat nou als mijn product uit het assortiment gehaald is? dan wil ik lang niet altijd dat dit nog terug te vinden is op de website, dan toon je dus een 404. met de bijbehorende 404 melding die ik op mijn site gebruik.

Ik vind dit een hele slechte zaak voor websites, voor gebruikers is dit leuk maar als webeigenaar wil je gewoon data kunnen verwijderen zonder een 301 te gebruiken.

[ThomasG]

Je kunt je ook afvragen of dat wel correct gebruik van een 404 pagina is, zeker bij een systeem als een webshop met historische gegevens.

Stel ik kom op jouw web-shop, en sla een product op in mijn favorieten. Een maand later kom ik terug, en krijg plotseling een 404 Not Found. Dan wordt ik daar niet blij van. Of er is een blog die linkt naar jouw product, en ik kom een half jaar later op die blog en denk: "Dat product wil ik wel.", maar jouw webshop geeft een 404. Dan wordt ik daar niet blij van, en koop waarschijnlijk niets bij jouw webshop.

Een betere manier is om een pagina te krijgen met: "Dit product zit niet meer in ons assortiment." Wellicht met links naar alternatieve vergelijkbare producten. Net zoals dat wanneer je "/pagina" hiernoemt naar "/nieuw" geen 404 moet geven op "/pagina", maar een 301 naar "/nieuw". Zodat de zoekmachines worden bijgewerkt.

[CJ_Latitude]

Die pagina waarop staat dat het product niet meer bestaat kan prima met status code 404 geserveerd worden, want de resource waar naar gezocht wordt is niet beschikbaar in de webwinkel.

[ThomasG]

En dat is dus foutief gebruik van een 404 status code, wat helaas te veel voorkomt. Een 404 betekend namelijk dat de pagina niet bestaat, en voorzover de server dat weet nooit bestaan heeft. Wanneer de server/web-site weet dat de pagina (product) bestaan heeft, maar niet meer bestaat hoor je volgens de standaarden en conventies een 410 Gone te geven, en geen 404 Not Found.

[Sjohn21]

Ook dat is niet geheel waar.


10.4.11 410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.

[supersnathan94]

In theorie hoor je überhaupt geen fouten te serveren naar je front end. En al helemaal niet in een webshop environment naar je klant. Als een product niet meer in het assortiment zit dan vermeld je dat op desbetreffende productpagina of je geeft een redirect naar een pagina waarop dat te lezen is. Dat is dus geen 404. Een 404 is een HTTP statuscode om aan te geven dat je een request doet naar een pagina die er niet is. Dus niet dat een product niet is gevonden.

[Wim-Bart]

404, 410 is inderdaad gewoon een slechte zaak. Bij een goede afhandeling moet je gewoon op de site uit komen en het liefst op een pagina die bijvoorbeeld zegt:

Product wat u zocht is niet meer leverbaar;
Artikel waat u naar zocht is niet meer beschikbaar.

Het moet gewoon netjes worden opgelost.

[Anoniem: 665613]

En die pagina met "het product dat u zocht...." Kan prima met een 4xx code geserveerd worden. Mensen lezen de pagina en snappen het, machines de code en snappen het.

[Blokker_1999]

Maar waarom zou je dat doen, je geeft je bezoeker nog altijd een pagina met bijkomende informatie (namelijk dat het artikel niet gevonden is ipv dat de pagina niet gevonden is), is een 404 dan nog wel terecht?

[supersnathan94]

Nee dat kan niet want een 404 betekent gewoon letterlijk dat er geen info beschikbaar is als response op de vraag. Door aan te geven dat het product niet aanwezig is geef je inhoudelijk een respons terug. Een 404 is feitelijk een Null pointer exception. Daar zit geen info in. Dat is iets anders dan een lege 200 return.

Desalnietemin zou je natuurlijk nooit op een pagina uit moeten kunnen komen vanaf jouw site die niet meer beschikbaar is. Als het product niet meer leverbaar is cq uit het assortiment is, waarom kan je dan nog wel op die pagina komen? Volgens mij is je CMS dan niet helemaal goed ingesteld.


Extern kan ik het me voorstellen via een permalink op een forum ofzo, maar dan zou je gewoon een generieke 404 moeten serveren dus niet specifiek van: hee, shit nummer 148 is niet meer leverbaar, maar: "sorry je probeert een pagina te bereiken die niet bestaat. Het kan zijn dat het product wat je zoekt niet meer wordt geproduceerd en je hier via een half jaar oude forumpost bent gekomen. Helaas pindakaas. Try googling that shit."

Dit kan netjes generiek op een path worden gezet als 404 pagina. De daadwerkelijke statuscode is dan ook een true 404. Lekker generiek pagina is er echt niet.

Zolang je geen 418 gebruikt is het in ieder geval goed.

[Anoniem: 665613]

Onzin.

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

[supersnathan94]

Exact. Body info is dus:
Niet gevonden,
Permanent.

De javascript code in je shop zou vervolgens zelf moeten snappen dat je net op een interne link hebt geklikt en dat dit product dus niet meer beschikbaar is.

Dit soort shit moet je niet vanuit de API kant oplossen. 4xx errors is client side dus vang je het daar ook af. 5xx is server side dus dan mag de beschrijving wel uitgebreid.

Groot verschil.

[Anoniem: 665613]

Niet alles is een API. En als je dynamische informatie in je "Not found" wilt hebben zul je alsnog een payload meesturen, of dat nu HTML, JSON, of whatever is.

[supersnathan94]

Als je RESTful info op wil halen is dat vrijwel altijd een API call die je maakt. Je kan binnen het frontend vervolgens de 404 afvangen. Het is een client error. Dit handel je dus ook client side af. Een 5xx handel je toch ook intern op je server af? Dan is foutinformatie wel gewenst aanezien je client geen idee heeft wat er fout kan gaan en waarom.

[erikmeuk3]

Ik los het op met een ouderwetse 204
Maar uiteindelijk is alles vergankelijk en zal het een 404 worden.

[Ayporos]

Mee eens. Als je toch al een productpagina had voor het betreffende artikel is het weinig moeite om je site zo te bouwen dat je met een vinkje dat product op non-actief kunt zetten en de bezoeker gewoon de productpagina te zien krijgt met de melding dat dit product niet meer leverbaar is en/of deze pagina verwijderd is (in geval van non-webshops) en als je dan netjes wilt zijn met een datum van status wijziging.

Als er iets is waar ik me aan erger is het wanneer ik een 404 voorgeschoteld krijg wanneer ik ergens op een link druk voor een pagina die overduidelijk wel (ooit) bestaan heeft.

Nou moet ik uiteraard wel zeggen dat, met dit als uitgangspunt, het hele idee van Mozilla dus berust is op websites die incorrect gebruik maken van de 404 code en, buiten het feit om dat de webbeheerder dit hoogstwaarschijnlijk onwenselijk acht, het ook nog eens technisch gezien dus niet juist is om te doen.

Ik heb niks tegen websites/crawlers zoals wayback machine of internet archive, maar als ik zo'n service wil gebruiken dan bepaal ik dat zelf wel in die unieke gevallen waar ik acht dat het meerwaarde heeft.

[Niosus]

Een 404 is een HTTP statuscode om aan te geven dat je een request doet naar een pagina die er niet is. Dus niet dat een product niet is gevonden.

Dat is dus niet correct. URL staat voor "Uniform Resource Locator". Uiteindelijk zie je alles als pagina's, maar waar je naar vraagt is een resource. Op een pagina in een webshop vraag je de naar de product gegevens, dat is dus een resource die niet gevonden kan worden en dus een 404 waard. Je kan dus perfect een 404 status code teruggeven samen met een mooie pagina die uitlegt waar het mis gaat. De status code moet je niet al te technisch opvatten, je moet eerder naar de semantische betekenis de request kijken.

Een ander voorbeeld is wanneer een user een pagina probeert te bezoeken waar hij ingelogd voor hoeft te zijn "401 Unauthorized" te geven en dan ze naar een login pagina sturen.

Fouten gaan voorkomen. Links gaan dood, gebruikers proberen dingen te doen die niet OK zijn en er kunnen bugs zijn. Je moet natuurlijk een goede ervaring geven aan de klant, maar overal een 200 OK code op plakken is gewoon niet slim. Voor gebruikers maakt het niets uit, maar plots is het veel moeilijker om te ontdekken of er iets mis gaat (spikes in error codes doen meestal alarms afgaan in monitoring tools). Ook search engines gaan gewoon dode links blijven houden als je geen 404 status code teruggeeft, of blijven linken naar restricted pagina;s als je geen 401 teruggeeft.

[supersnathan94]

Ho. Ja je kan prima een 404 terug geven met daarbij een paina die uitlegt wat er dan precies aan de hand is, maar dat moet dan wel een generieke pagina zijn die alleen in die "directory" bij alle 404's wordt geserveerd. Wat je daarmee doet is de standaard server 404 vervangen door jou standaard 404.

Een pagina terug geven met: "het product X waar u naar zoekt is niet meer beschikbaar" is geen 404.

En zoals ik in een eerdere post al aangaf. Binnen de webshop zou een 404 alleen voor moeten kunnen komen doordat de gebruiker zelf met de URL loopt te knutselen. Niet omdat je website niet goed is bijgewerkt ofzo.

[Yaminike]

maar dat moet dan wel een generieke pagina zijn die alleen in die "directory" bij alle 404's wordt geserveerd.

Zeer fijn dat dat moet van jouw, maar dit is absoluut niet verplicht per specificatie, en als jij wel een HTTP specificatie kan vinden die dit expliciet verbiedt hoor ik dit zeer graag

Zie: https://tools.ietf.org/html/rfc2616#section-10.4.5

Tevens is jouw oplossing totaal niet gebruiksvriendelijk, want niet geheel onbelangrijk is als je ergens je geld mee verdient.

Zie overigens ook: https://tools.ietf.org/html/rfc2616#section-10.4

• Except when responding to a HEAD request,
  the server SHOULD include an entity containing an explanation of the
  error situation
• User agents SHOULD display any included entity to the user

[Reactie gewijzigd door Yaminike op 22 juli 2024 19:34]

[supersnathan94]

Hoezo is het niet gebruiksvriendelijk? Je geeft gewoon netjes aan dat een artikel niet gevonden is. Welk artikel dat is is totaal irrelevant. Het hoeft niet gebruiksvriendelijker te zijn aangezien de gebruiker de URL verkeerd heeft getypt of express heeft lopen graven. Het enige wat je aan hoeft te geven is: "sorry maar je doet iets niet goed, want dit snappen we echt niet".

[Niosus]

Ho. Ja je kan prima een 404 terug geven met daarbij een paina die uitlegt wat er dan precies aan de hand is, maar dat moet dan wel een generieke pagina zijn die alleen in die "directory" bij alle 404's wordt geserveerd. Wat je daarmee doet is de standaard server 404 vervangen door jou standaard 404.

Een pagina terug geven met: "het product X waar u naar zoekt is niet meer beschikbaar" is geen 404.

Euhm, nee? De HTTP status code is maar een veldje in de header. Binnen mijn webapplicatie kan ik gewoon kiezen welke status ik aan een pagina mee geef. Ik genereer de pagina, zet 404 in de header en klaar. Als ik wil kan ik zelfs vriendelijk de gebruiker aanspreken met zijn voornaam (als hij ingelogd is) op de 404 pagina. Hoeft absoluut niet generiek te zijn en die standaard 404 die werkt nog steeds. Ik werk natuurlijk wel niet met de kant-en-klare CMS'en zoals Drupal of Wordpress. Ik werk een laag eronder waar ik volledige controle heb over wat er nu precies naar de gebruiker gestuurd word. Ik vermeld zelfs "404" niet op mijn 404 pagina, maar toch is dat echt wel de status code van die HTTP request. Zoals ik al zei: verwar het technische deel niet met het semantische. Technisch gezien is het een pagina binnen de website zoals een andere, maar semantisch gaat het om een link naar een resource die niet bestaat dus het krijgt de 404 code. Dat veel sites 1 generieke 404 pagina gebruiken is hun zaak, maar absoluut niet wat moet volgens de specificatie. De enige reden dat dit de de-facto standaard is is omdat webservers gewoon standaard een generieke 404 pagina gebruiken en developers er niet bij nadenken om het wat beter aan te pakken.

[Reactie gewijzigd door Niosus op 22 juli 2024 19:34]

[Yaminike]

@Win-Bart (foutje met de reactie)

4xx valt onder de 'Client Errors', Client errors geven aan dat de client iets opvraagt waarvan de server al weet dat het niet goed is en het ook kan oplossen. 5xx zijn 'Server Errors' zijn meer fatal errors.

En aangezien je gewoon content kan serveren terwijl je een status 410 of 404 meegeeft, zie ik het probleem hier ook niet van.

In theorie hoor je overigens juist wel Client Errors te sturen, dit zodat de client weet wat er aan de hand is, vooral crawlers zijn hier erg blij mee.

En in het geval, 'Dus niet dat een product niet is gevonden.'
In een webshop environment staat een product gelijk aan een detail pagina, is het product dus niet meer te vinden in de database (hard delete) moet er een 404 worden gestuurd (bij een soft delete eventueel een 410) en het liefst ook een pagina die zegt dat het product niet te vinden is, dus niet dat de pagina niet te vinden is.

[Reactie gewijzigd door Yaminike op 22 juli 2024 19:34]

[supersnathan94]

Nee. Een hard delete moet er voor zorgen dat je uberhaupt niet meer op die pagina kan komen vanuit de site zelf. Dus alleen externe aanvragen via URL hardcoding/favorites houd je dan nog over. In dat geval moet je gewoon een 404 opgeven die generiek aangeeft joh wat je probeert te doen heeft geen nut want die data bestaat niet. En voor zover ik weet heeft het ook nooit bestaan.

Ja je kan content meegeven, maar dat is niet de bedoeling. Een 404 is feitelijk een null pointer. Je kan dus details meegeven waarom de pagina niet beschikbaar is, maar zeggen dat een product niet meer bestaat is geen 404 maar een 410.

[ucsdcom]

Nou, weer veel verschillende meningen hier. Zeer interessant te lezen! Tegelijkertijd is dit een heel nodige discussie. Blij dat die weer een keer gevoerd wordt hier.

Wat mij betreft moet DE trigger om hier altijd over na te denken zijn: hoe zal de klant dit ervaren?
Het verbaasd mij telkens weer als ik zie dat gerenomeerde websites doorverwijzen naar "niet bestaande" pagina's. Meestal kom je hier al vanaf de homepage als je zoekt naar een product, soms vanuit Google, soms vanuit een tip in een forum, op social media of iets dergelijks. Vooral als je via een homepage of reclame uiting op een 404 pagina uit komt is dat irritant. Dit zie je vooral als je bij producten of voorwaarden op "details" of "meer informatie" klikt. Je hebt dan meteen het idee dat er onvoldoende tijd gestopt is in het goed maken van de klantbeleving.

[supersnathan94]

Eens. Desbetreffende shop moet dus ook gewwerd worden. Interne links mogen nooit en te nimmer op 404's eindigen. Zeker geen "details" pages.

Het punt is alleen dat je geen 404 moet serveren als vervanging van "product X is uit het assortiment". Dat is ten eerste een 410 en daarnaast is dit voor de webserver een kompleet irrelevant iets. Binnen een webshop kunnen dergelijke dingen niet. Je API kan prima een 404 opgeven waarna de scripts op de site gaan nadenken wat er fout gaat. Je kan prima clientside bijhouden welk product "product X" is. Je webserver hoort geen "404, product X is niet gevonden want zus en zo, en database en moeilijk en ik snap het niet" op te gooien, maar een simpele "404, not found". Vervolgens de kt jouw webshop ja maar ik had net een klik op product x. Kennelijk bestaat deze niet meer.

[Primal]

Ik ben het met ThomasG eens, hij bekijkt het vanuit de gebruikerskant i.p.v. de technische kant. Ik ben als gebruiker helemaal niet geïnteresseerd of de "resource" niet bestaat. Dat is voor het overgrote deel van de gebruikers niet begrijpelijk, zij willen gewoon het product bestellen. Is het product niet meer aanwezig, dan wil ik dat als gebruiker in Jip-en-Janneke taal zien en niet e.e.a. technische melding met code 404 en nog wat andere technische informatie. Of beter nog: een pagina waarop je vermeld dat het product niet meer aanwezig is en er daarnaast enkele alternatieven getoond worden.

[mrdemc]

Zoals hierboven aangegeven is 404 een HTTP Status code. Naast de statuscode kun je prima de website zelf serveren maar dan met de melding dat de pagina of het product niet meer bestaat. Het verschil tussen een 404 en een 410 is dat je bij een 410 moet blijven bijhouden dat de pagina ooit heeft bestaan terwijl bij een 404 deze informatie niet beschikbaar hoeft te zijn; hij is er gewoon niet (meer?). Een 404 is dus een prima gewoonte hiervoor. Ik vind dan ook dat ze hiermee de plank misslaan; maar misschien doen ze dit wel alleen bij pagina's die daadwerkelijk géén inhoud serveren bij deze statuscode?

[kozue]

Er zijn geen 404 pagina's zonder inhoud. Zelfs de standaard 404 van apache of nginx heeft html-inhoud.

[edit:] @mrdemc:
Dat was m'n punt helemaal niet. Ik bouw dagelijks webapplicaties én REST API's. Ik weet dat je, technisch gezien, gewoon een 404 terug kunt geven zonder content. Maar in de praktijk gebeurt dit niet omdat een 404 alleen niet voldoende is. Bij een API wil je een degelijke foutmelding terug krijgen (waarschijnlijk in json of xml formaat, afhankelijk van hoe je API werkt), en bij een website/applicatie wil je de gebruiker beter van dienst zijn dan alleen een witte pagina die doet vermoeden dat de content er nog aan komt. Daarom mijn opmerking: zelfs de standaard response van webservers bevat content, omdat een lege response gewoon nergens op slaat, in geen enkele situatie.

[Reactie gewijzigd door kozue op 22 juli 2024 19:34]

[mrdemc]

Zoals eerder gezegd is een 404 een http status en wordt dat meegegeven in de header. Dat jij of jouw server is ingesteld om een standaard pagina mee te sturen wil niet zeggen dat het altijd zo is. Je kunt prima een 404 status zonder inhoud hebben en dan is de pagina die je ziet er eentje geserveerd door de browser. Daarom zien ze er vaak ook anders uit per browser. Ze zijn er dus wel degelijk.

[RobinF]

Onder andere Coolblue laten netjes hun "oude" producten op de website staan. Ze zijn alleen niet te vinden in hun eigen zoekmachine. Wel via o.a. Google en Mijn Bestellingen.

[johnkeates]

Ja dat kan. Dit is geen slechte zaak en nog steeds 100% in controle van de beheerder.

Je kan:

- Redirect naar product bestaat niet meer
- Wayback machine de pagina laten verwijderen
- Google de pagina laten verwijderen, ook uit z'n cache
- 404 serveren
- Vooraf aangeven dat je niet vindbaar wil zijn, niet in wayback machine wil komen en het liefste gewoon geen bezoekers wil hebben, mag allemaal.

[Reactie gewijzigd door johnkeates op 22 juli 2024 19:34]

[RagingPenguin]

Al haal je product uit het assortiment is het beter om in je database op te slaan dat het product niet meer geleverd word en dit weer te geven op je site, compleet met alternatieven. Dan heb je een gebruiksvriendelijkere site en je maakt meer kans om alsnog iets te verkopen. Niets betekende errors als 400-codes zou je zo veel mogelijk moeten vermijden.

[Eitot]

Als jij niet wilt dat jouw website (of delen daarvan) geïndexeerd wordt, dan kun je dat als beheerder gewoon aangeven. Archive.org respecteert dat. Feitelijk komt het er in dit geval gewoon op neer, om een analogie te maken, dat mensen in een archief oude reclamefolders or catalogi van jouw winkel tegenkomen, terwijl dat aanbod niet meer bestaat. Als je iets in het openbaar verspreidt, moet je ook accepteren dat mensen dat ergens bewaren of verzamelen.

Zoals op de screenshots te zien is, geeft Firefox dan gewoon een melding met een verwijzing naar archive.org, dus ze presenteren het niet naadloos zodat je ze indruk zou kunnen krijgen dat het nog een actuele pagina is. Ik vind dat eigenlijk wel een goede zaak, Google doet dat namelijk ook al heel lang en het is handig als een server tijdelijk problemen heeft.

[dasiro]

ze moeten dit vragen, niet eisen dat je zelf preventief er iets tegen doet en ondertussen al je content rippen

[aaimaai]

Er zijn voldoende manieren om te zorgen dat je in zo'n geval geen 404 response geeft maar een redirect naar een andere pagina.

[WokeBroke]

Dat gebeurd toch ook niet? Zoekmachines indexeren toch niet met Mozilla ?

[Tirinium]

Perfecte oplossing vind ik zelf, het zou hier dan ook alleen moeten gaan om sites die echt offline zijn gegaan echter (Denk bijvoorbeeld aan bepaalde webcomics waarvan de hosting gestopt is.) en niet om pagina's die verwijderd zijn door de site admin van een bestaande website, omdat ze niet langer relevant zijn of omdat ze inbreuk maken op rechten van anderen.

[Zwijntjesdrecht]

Helemaal mee eens. Flauwekul zeg.

[Anoniem: 333920]

Handig! Bestaat een dergelijke Chrome extensie ook?

Het zou overigens erg mooi zijn als er een zoekmachine voor het Internet Archive komt, het verbaast me dat Google of Microsoft daar nog niet in is gesprongen.

[XiniX88]

https://chrome.google.com...hmegjfffjogbdefcbddmmchea

Deze bijvoorbeeld. 404 -> Google cache, en indien niet gevonden de Wayback Machine

[ThomasG]

Als er een Google Chrome extensie komt, denk ik dat er een aannemelijke kans is dat dit gecombineerd wordt met de Google Cache. Het nadeel van Google Cache is echter dat pagina's welke voor langere tijd (2-3 weken) een 404 geven uit de cache worden verwijderd. Er zijn namelijk een hoop websites die niet in The Wayback Machine worden opgeslagen, maar wel in caches van o.a. Google.

[MrMonkE]

Nu kan the wayback machine ook een api gaan schrijven om de miljoenen 'right to be forgotten' aanvragen te kunnen verwerken die hierdoor gaan ontstaan.

[Midas.e]

Wat geen probleem is, archive.org heeft dit al en zal de content dan 'dark' maken. Afhankelijk of je nou ook werkelijk aanspraak daarop kan maken.

[MadEgg]

Waarom die validatie? Plak er gewoon een rechtstreekse link bij naar de pagina op Wayback machine om daar te zoeken, indien gewenst. Dan hoeft er niet elke keer data verzonden te worden. Tja, dan zul je wat missers hebben, maar dat maakt niet uit. In veel gevallen weet de gebruiker ook wel wat ze zelf een fout hebben gemaakt en dat de pagina niet opeens verdwenen is maar er gewoon nooit geweest is.

Die link lijkt me wel handig; ik gebruik zelf soms ook de Wayback Machine om op dezelfde wijze pagina's terug te vinden. Maar geautomatiseerd hoeft er natuurlijk niets verzonden te worden, zoals met alles. Waarom dat zo'n trend is tegenwoordig?

[Flumble]

Waarom dat zo'n trend is tegenwoordig?

Het is een makkelijke en redelijk betrouwbare manier voor Mozilla om te kijken of die feature nuttig genoeg is om standaard in de browser te steken (het levert toch weer extra complexiteit op) en het gros van de mensen geeft niks om hun privacy.

[johnkeates]

Eigenlijk een soort van wayback-machine-powered-cloudflare

[Booster]

Ik weet niet of de add-on Resurrect pages nog goed werkt, maar deze bood ongeveer dezelfde functie, met knoppen voor Google Cache, The Wayback Machine (archive.org), WebCite en archive.is. Bij een 404 krijg je een menu aangeboden om te kiezen uit die vier archieven.

https://addons.mozilla.or...ox/addon/resurrect-pages/

Verder natuurlijk prima dat Mozilla eens kijkt hoe een functie als deze door de gemiddelde gebruiker uit de testgroep gebruikt wordt. Voor sommige onderzoekers lijkt het me nuttig, maar ik denk dat de gemiddelde Firefox gebruiker er niet veel aan heeft.

[Reactie gewijzigd door Booster op 22 juli 2024 19:34]

[onetime]

Je bent me voor. Resurrect pages wilde ik ook al melden. En eens met je. Gebruik het al jaren.
En dan kan je zelf beslissen of het de moeite is om een archief te raadplegen. En welke.

[uip]

ik wil ook op een andere actie wijzen om 404-foutmeldingen beter te gebruiken: http://notfound.org
zij tonen foto's van verdwenen kinderen op de 404 - pagina's. Zo hebben die nog hun nut :-)

[Anoniem: 636203]

Wanneer komt Mozilla nou eens met Tor ondersteuning in Firefox? Dat zou hun browser echt onderscheiden van de rest, zeker wat privacy betreft.

De eerste aankondiging hierover was in 2014, sindsdien hoor ik er weinig meer over.

[Reactie gewijzigd door Anoniem: 636203 op 22 juli 2024 19:34]

[Loekie]

Mjah, daarmee vervalt de laatste reden om nog firefox te gebruiken. Regelmatig cached firefox redirects en pagina's waardoor het testen van redirects, CDN en changes met firefox een drama is. Edge en Chrome zijn daar tegenwoordig beter voor te gebruiken.

[Macshack]

Ik ben ook eens dat als je als admin een bepaalde pagina niet MEER wilt serveren dat je dan een 410 teruggeeft (mooier nog is een trip yet succeed beleid hanteren. Dus een 308). Bij een 404 geef je aan dat de client het in de toekomst nog een keer kan proberen. Maar bij een bewuste verwijdering is de intentie dat die resource er nooit meer zal zijn.