De negatieve dereference-cache is geen censuurknop meer (shaer-qawr)
De cache onthield elke mislukte dereference op de note-URI alleen, en een
van de twee manieren om te mislukken is volledig door een vreemde te
sturen. Neem de echte note-URI van je slachtoffer, zet je eigen actor op
DEZELFDE host als beweerde afzender en wijs met inReplyTo naar een van
onze publieke notes: de fetch bij de bron slaagt, attributedTo is het
slachtoffer en niet jij, en die note-URI stond dertig minuten op de
zwarte lijst. Het echte doorgestuurde antwoord liep daar daarna op stuk.
Elke dertig minuten herhalen gaf onbeperkte, gerichte onderdrukking van
een specifiek antwoord, voor een verzoek per keer.
De sleutel is nu de hele bescherming, want de twee soorten mislukking
zeggen iets verschillends. Een TRANSPORTFOUT is een eigenschap van de
note zelf en geldt voor iedereen die hem doorstuurt: sleutel is de
note. Een attributedTo-MISMATCH zegt iets over DEZE doorstuurder:
sleutel is (note, beweerde actor). De leugenaar remt daarmee alleen
zichzelf af, en dat was de rem die de cache moest zijn.
Tweede punt uit dezelfde bead: query en fragment tellen niet meer mee in
de sleutel. Met een kale URL waren ?x=1 en ?x=2 losse ingangen, dus
varieren kostte niets en er was helemaal geen rem -- en met vijfhonderd
losse sleutels waren de echte ingangen eruit te duwen.
Bewust NIET gedaan: een rem per HOST. Wie een handvol niet-bestaande
URL's op een host laat mislukken zou daarmee die hele host het zwijgen
opleggen, en dat is een grotere versie van precies de fout die hier
gerepareerd wordt. Dat staat als waarschuwing bij de code.
Drie toetsen, elk met eigen tegenbewijs: met de sleutel terug op de note
alleen valt de censuurtoets en blijven de andere twee groen, en met de
URL-normalisatie eruit valt alleen de remtoets. Volle suite 1237.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
