Teilanfragen: Sprachnachrichten kommen jetzt auch auf dem iPhone an
Filipe: „zeurst schaust du mal ob es im system liegt dass miss, die modi,
keine sprachnachrichten hoeren kann oder ob es an ihr liegt weil bei allen
anderen klappt nur bei ihr nicht"
ES LAG AM SYSTEM.
WAS GEMESSEN WURDE (nicht vermutet)
1. An ihrer Rolle liegt es nicht. Der Weg `/workspace/api/chat/anhang/:id`
fragt drei Dinge: gibt es die Nachricht, ist die Person im Raum, hat sie
das Gespraech weggeraeumt. Keine Rollenpruefung. Gegen eine Wegwerf-
Datenbank gemessen: `anmelden admin=200 modi=200`, Anhang als modi
HTTP 200, 40018 Bytes -- genau wie als admin.
2. Sie ist in allen drei Raeumen mit Sprachnachrichten, geloescht_bis = 0,
alle sechs Tondateien liegen auf der Platte. (Live-Datenbank, nur
gelesen, auf einer Kopie, Kopie danach geloescht.)
3. Sie ist die EINZIGE im Haus mit Safari. Aus dem Caddy-Protokoll, ueber
IP und Minute mit ihren Protokolleintraegen abgeglichen: iPhone,
iOS 18.7, Safari 26.6.1. Alle anderen Geraete der letzten zwei Wochen:
Android-Chrome 3900 Anfragen, Windows-Chrome/Edge/Firefox 2646.
Neun von zehn iPhone-IP-Praefixen sind ihre.
4. DER FEHLER: Der Anhang-Weg beantwortete eine Teilanfrage
(`Range: bytes=0-1`) mit einer vollen HTTP 200 -- ohne `Accept-Ranges`,
ohne `Content-Length`, als `chunked`. Zum Vergleich dieselbe Anfrage an
`express.static`: HTTP 206, `accept-ranges: bytes`,
`content-range: bytes 0-1/2480`.
Safari verlangt fuer <audio> und <video> zwingend Teilanfragen und
verweigert die Wiedergabe bei einer 200. Chrome und Firefox nehmen die
ganze Datei klaglos. Bilder brauchen das nicht -- deshalb sah sie Fotos
und hoerte nichts, und deshalb fiel es sieben Tage lang nur ihr auf.
WAS GEAENDERT IST
A) EIN GEMEINSAMER AUSLIEFERWEG (server/helfer-ausliefern.mjs)
Im Haus gaben ZEHN Stellen eine Datei mit `createReadStream(pfad)
.pipe(res)` hinaus: Chat-Anhang, Chat-GIF, Dateiablage (ansehen und
laden), Material (ansehen und laden), Steckbriefbild, Buehnenbild,
Supportbild, Wissens-PDF. Nur eine davon zu reparieren hiesse, eine
Liste zu fuehren, welche Stelle schon richtig ist -- und die naechste
neue macht es wieder falsch. Alle zehn gehen jetzt ueber
`liefereDatei(req, res, pfad)`: `Accept-Ranges`, `Content-Length`,
206 mit `Content-Range`, 416 mit `bytes */groesse`. Mehrere Bereiche in
einer Anfrage werden absichtlich nicht bedient (das darf ein Server);
die Antwort ist dann die GANZE Datei, nie eine falsche Teilmenge.
WAS ES AUSSER SAFARI BRINGT, gemessen: Eine MP4-Sprachnachricht meldete
in Chromium ohne Teilanfragen 0,23 s statt 1,96 s Laenge -- der Kopf
einer MP4 steht am Ende der Datei. Eine Ogg-Datei meldete „Infinity"
statt 2,02 s. Und ein PDF-Betrachter springt jetzt zu einer Seite, ohne
die ganze Datei zu holen.
B) AUFGENOMMEN WIRD AAC IN MP4 (workspace/assets/js/chat.js)
Die Reihenfolge der Behaelter beantwortete bisher die Frage „was kann
DIESES Geraet am liebsten". Richtig ist „was koennen die ANDEREN
abspielen" -- die hoeren es.
Gemessen mit echten Aufnahmen aus echten Browsern, danach in beiden
Engines abgespielt:
Chromium nimmt auf: webm/opus, mp4(AAC), mp4(Opus)
Firefox nimmt auf: webm/opus, ogg/opus -- MP4 gar nicht
Beide spielen alle vier Behaelter vollstaendig ab (2 s rein, 2 s raus)
ZWEI FALLEN, die die Messung gezeigt hat:
- Ein blankes `audio/mp4` ist nicht AAC: Chromium meldet darauf
`audio/mp4;codecs=opus` zurueck -- MP4 aussen, Opus innen, fuer Safari
genauso unbrauchbar wie WebM. Deshalb steht `audio/mp4;codecs=mp4a.40.2`
VOR dem blanken `audio/mp4`.
- Firefox kann kein MP4 aufnehmen und faellt sauber auf WebM/Opus
zurueck. Kein Rueckschritt -- das ist der heutige Stand.
Die Pruefung nimmt jetzt im echten Browser ueber den echten Knopf auf,
und der Server erkennt: audio/mp4, 45583 Bytes, 2734 ms.
BERICHTIGT: In zwei Kommentaren stand „Safari und das iPhone koennen
nur MP4". Das stimmt nicht. An Miss' eigener Aufnahme nachgemessen:
Behaelter WebM, Mux-Programm „WebKit", Tonspur A_OPUS. Safari NIMMT
WebM auf -- ob es WebM abspielt, ist eine andere Frage.
C) EIN AUSWEG STATT EINER VERTROESTUNG (chat.js, chat.css)
Vorher stand im Fehlerfall „Sprachnachricht laesst sich gerade nicht
laden". Das war fuer Miss die ganze Auskunft, und es stimmte nicht
einmal: Die Datei kam an, ihr Browser konnte den Behaelter nicht.
„Gerade" heisst „gleich nochmal versuchen" -- bei einem fremden
Behaelter hilft kein Versuch mehr.
Jetzt wird unterschieden (Fehlercode 4 = Format, alles andere = Laden)
und daneben steht ein Weg, der wirklich zum Ton fuehrt: Herunterladen,
44 px hoch, in der Farbe der Blase, mit eigenem Vorlesewort. Nur im
Fehlerfall -- ein Knopf an jeder Sprachnachricht waere Unordnung fuer
alle, damit einer Person geholfen ist.
WAS JETZT NACHGEZAEHLT WIRD
- pruef-chat-anhaenge: 119 -> 146 Pruefungen. Dreizehn davon messen
Teilanfragen am Foto (0-9, -8, 5-, ueber das Ende hinaus, 416, mehrere
Bereiche, unverstandener Kopf) und vergleichen jeden Abschnitt BYTEWEISE
mit der vollen Datei -- eine 206 mit den falschen Bytes waere schlimmer
als keine. Drei Gegenproben legen dieselbe Messlatte an erfundene
Antworten (die alte volle 200, falsche Gesamtgroesse, falsche Bytes) und
muessen durchfallen. Neun weitere pruefen die Sprachnachricht selbst und
den Ausweg.
- pruef-wissen-neu: +6. Der Weg zur PDF war der EINZIGE der zehn, den nie
eine Pruefung abgerufen hat -- genau der, bei dem eine Umstellung
unbemerkt danebengeht. Jetzt beide Spielarten (ansehen und laden).
- pruef-struktur: +6. Wer kuenftig wieder `createReadStream(...).pipe(res)`
schreibt, bekommt einen Befund. Mit Gegenproben in beide Richtungen; die
Probetexte sind zusammengesetzt, sonst meldet die Wache ihre eigene
Begruendung als Fund. Pruefdateien sind ausgenommen, weil sie an niemanden
ausliefern -- dort ist ein Weg ohne Teilanfragen die Gegenprobe.
(Beim ersten Lauf hat die Wache sofort meine eigene Messdatei gefunden.)
WAS NICHT NACHGESEHEN WERDEN KONNTE
Ob iOS-Safari WebM/Opus ueberhaupt abspielt. Playwrights WebKit startet auf
diesem Rechner nicht (`icuuc77.dll`, auch nach Neuinstallation), und ein
iPhone habe ich nicht. Der dritte Ausgang: konnte nicht nachsehen. Deshalb
sind A, B und C drei Sicherungen hintereinander statt einer Wette auf eine.
GEPRUEFT (alles einzeln, kein Gesamtlauf)
pruef-chat-anhaenge 146 ok pruef-material 159 ok
pruef-wissen-neu 33 ok pruef-spenden 172 ok
pruef-struktur 85 ok pruef-support 63 ok
pruef-video 74 ok pruef-steckbrief 65 ok
pruef-galerie 26 ok pruef-eintrag-bild 24 ok
pruef-chat 63 ok pruef-chat-optik 62 ok
pruef-haus-trennung 100 ok
Die beiden Haeuser bleiben getrennt (pruef-haus-trennung, 100 ok). Der
Ausliefer-Weg gehoert beiden gleichermassen und traegt nichts Haus-
spezifisches; die Aufnahme betrifft faktisch nur Team Dogi, weil nur dort
der Mikrofonknopf steht („also nur die modis rechte linke hand und
dogfather").
NICHT VON MIR, SCHON VORHER ROT: pruef-gifs meldet zwei Fehler („das GIF
steht danach wirklich im Verlauf", „die Tafel geht zu"). Gegen den
unveraenderten Stand von HEAD nachgemessen -- dieselben zwei Fehler, mit
denselben Zahlen. Ein eigener Befund, kein Nebenschaden dieser Arbeit.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
Claude Opus 5
@@ -675,6 +675,107 @@ melde("\n=== 4. Ausliefern ===");
|
||||
}, bildNachrichtId);
|
||||
ok(/^attachment/.test(alsDownload || ""), `mit ?laden=1 wird es ein Download (${alsDownload})`);
|
||||
|
||||
/* ===================================================================
|
||||
TEILANFRAGEN (02.10.2026)
|
||||
|
||||
WARUM DAS HIER STEHT: Miss, eine Modi, konnte keine
|
||||
Sprachnachrichten hoeren. An ihrer Rolle lag es nicht -- der Weg
|
||||
hier kennt gar keine. Sie ist die Einzige im Haus mit Safari
|
||||
(iPhone, iOS 18.7), und Safari verlangt fuer <audio> und <video>
|
||||
zwingend Teilanfragen. Der Weg antwortete auf `Range: bytes=0-1`
|
||||
mit einer vollen 200, ohne `Accept-Ranges`, ohne
|
||||
`Content-Length`, als `chunked`. Chrome und Firefox nehmen das
|
||||
klaglos -- deshalb fiel es sieben Tage lang nur ihr auf.
|
||||
|
||||
GEPRUEFT WIRD NICHT NUR DER STATUS, SONDERN DER INHALT: Eine 206
|
||||
mit den falschen Bytes waere schlimmer als gar keine. Jeder
|
||||
Abschnitt wird deshalb gegen die volle Datei gehalten.
|
||||
=================================================================== */
|
||||
const holen = (id, kopfzeilen) => luna.seite.evaluate(async ([i, h]) => {
|
||||
const a = await fetch(`/workspace/api/chat/anhang/${i}`, { cache: "no-store", headers: h });
|
||||
const b = new Uint8Array(await a.arrayBuffer());
|
||||
return {
|
||||
status: a.status,
|
||||
bereiche: a.headers.get("accept-ranges"),
|
||||
laenge: a.headers.get("content-length"),
|
||||
abschnitt: a.headers.get("content-range"),
|
||||
bytes: [...b],
|
||||
};
|
||||
}, [id, kopfzeilen || {}]);
|
||||
|
||||
const ganz = await holen(bildNachrichtId);
|
||||
const GROESSE = ganz.bytes.length;
|
||||
ok(ganz.status === 200 && GROESSE > 100, `die ganze Datei kommt (${GROESSE} Bytes)`);
|
||||
ok(ganz.bereiche === "bytes",
|
||||
`der Server sagt, dass er Abschnitte kann: Accept-Ranges: ${ganz.bereiche}`);
|
||||
ok(Number(ganz.laenge) === GROESSE,
|
||||
`und wie lang sie ist (Content-Length ${ganz.laenge}) -- ohne das sucht Safari gar nicht erst`);
|
||||
|
||||
/** Stimmt eine Teilantwort? Status, beide Kopfzeilen UND die Bytes.
|
||||
* Als eigene Funktion, damit die Gegenprobe weiter unten dieselbe
|
||||
* Messlatte an eine erfundene 200-Antwort legen kann. */
|
||||
const abschnittStimmt = (a, von, bis) =>
|
||||
a.status === 206
|
||||
&& a.abschnitt === `bytes ${von}-${bis}/${GROESSE}`
|
||||
&& Number(a.laenge) === bis - von + 1
|
||||
&& a.bytes.length === bis - von + 1
|
||||
&& a.bytes.every((w, i) => w === ganz.bytes[von + i]);
|
||||
|
||||
const vorn = await holen(bildNachrichtId, { Range: "bytes=0-9" });
|
||||
ok(abschnittStimmt(vorn, 0, 9),
|
||||
`bytes=0-9 -> HTTP ${vorn.status}, ${vorn.abschnitt}, ${vorn.bytes.length} Bytes`
|
||||
+ " -- und es sind die richtigen");
|
||||
|
||||
const hinten = await holen(bildNachrichtId, { Range: "bytes=-8" });
|
||||
ok(abschnittStimmt(hinten, GROESSE - 8, GROESSE - 1),
|
||||
`bytes=-8 holt die LETZTEN acht (${hinten.abschnitt})`);
|
||||
|
||||
const bisEnde = await holen(bildNachrichtId, { Range: "bytes=5-" });
|
||||
ok(abschnittStimmt(bisEnde, 5, GROESSE - 1),
|
||||
`bytes=5- geht bis zum Ende (${bisEnde.abschnitt})`);
|
||||
|
||||
/* ZU VIEL VERLANGEN IST ERLAUBT und endet am Dateiende -- so fragt
|
||||
ein Abspielgeraet, das die Laenge noch nicht kennt. */
|
||||
const zuViel = await holen(bildNachrichtId, { Range: `bytes=0-${GROESSE + 500}` });
|
||||
ok(abschnittStimmt(zuViel, 0, GROESSE - 1),
|
||||
`wer ueber das Ende hinaus fragt, bekommt bis zum Ende (${zuViel.abschnitt})`);
|
||||
|
||||
/* AUSSERHALB IST ETWAS ANDERES ALS ZU VIEL: Dafuer gibt es 416, und
|
||||
die Groesse MUSS dabeistehen, sonst weiss niemand, was er
|
||||
stattdessen fragen soll. */
|
||||
const daneben = await absichtlich([luna],
|
||||
() => holen(bildNachrichtId, { Range: `bytes=${GROESSE + 10}-` }));
|
||||
ok(daneben.status === 416 && daneben.abschnitt === `bytes */${GROESSE}`,
|
||||
`ein Bereich hinter dem Ende: HTTP ${daneben.status}, ${daneben.abschnitt}`);
|
||||
|
||||
/* MEHRERE BEREICHE AUF EINMAL werden absichtlich nicht bedient --
|
||||
das darf ein Server. Die Antwort muss dann die GANZE Datei sein,
|
||||
nie eine falsche Teilmenge. */
|
||||
const mehrere = await holen(bildNachrichtId, { Range: "bytes=0-9,20-29" });
|
||||
ok(mehrere.status === 200 && mehrere.bytes.length === GROESSE,
|
||||
`mehrere Bereiche -> die ganze Datei (HTTP ${mehrere.status}, ${mehrere.bytes.length} Bytes)`);
|
||||
|
||||
const unsinn = await holen(bildNachrichtId, { Range: "haeppchen=0-9" });
|
||||
ok(unsinn.status === 200 && unsinn.bytes.length === GROESSE,
|
||||
`ein Kopf, den niemand versteht -> ebenfalls die ganze Datei (${unsinn.status})`);
|
||||
|
||||
/* ---- GEGENPROBE: Kann diese Messlatte ueberhaupt "nein" sagen? ----
|
||||
|
||||
Genau das war am 01.09. der Fehler: `every()` auf einem leeren
|
||||
Feld meldete gruen, ohne ein einziges Bild angesehen zu haben.
|
||||
Hier bekommt dieselbe Funktion drei erfundene Antworten -- die
|
||||
ALTE (volle 200), eine mit falschem Abschnitt und eine mit
|
||||
richtigem Kopf, aber falschen Bytes. */
|
||||
ok(!abschnittStimmt({ status: 200, abschnitt: null, laenge: String(GROESSE),
|
||||
bytes: ganz.bytes }, 0, 9),
|
||||
"Gegenprobe: die alte Antwort (volle 200) faellt durch");
|
||||
ok(!abschnittStimmt({ status: 206, abschnitt: `bytes 0-9/${GROESSE + 1}`, laenge: "10",
|
||||
bytes: ganz.bytes.slice(0, 10) }, 0, 9),
|
||||
" eine 206 mit falscher Gesamtgroesse auch");
|
||||
ok(!abschnittStimmt({ status: 206, abschnitt: `bytes 0-9/${GROESSE}`, laenge: "10",
|
||||
bytes: ganz.bytes.slice(5, 15) }, 0, 9),
|
||||
" und eine 206 mit den falschen Bytes ebenfalls");
|
||||
|
||||
/* WER NICHT IM RAUM IST, BEKOMMT NICHTS. DogFather sieht sonst
|
||||
überall alles -- hier ausdrücklich nicht: Ein Gespräch zwischen
|
||||
zwei anderen ist kein Bereich, den man verwaltet. */
|
||||
@@ -1019,6 +1120,104 @@ async function tonAufnehmen(seite, ms) {
|
||||
}, raumDogi));
|
||||
ok(alsVideo === 415,
|
||||
`ein Video im Ton-Behälter wird abgelehnt (HTTP ${alsVideo}) — sonst liefe es ohne Bild und niemand wüsste es`);
|
||||
|
||||
/* ===================================================================
|
||||
DIE SPRACHNACHRICHT SELBST, AUF DEM WEG ZUM OHR (02.10.2026)
|
||||
|
||||
Abschnitt 4 prüft die Teilanfragen am Foto. Hier wird dasselbe
|
||||
noch einmal an einer SPRACHNACHRICHT gefragt -- nicht aus
|
||||
Doppelung, sondern weil genau das der Fall war, der sieben Tage
|
||||
lang kaputt war: Ein Bild braucht keine Teilanfragen, ein
|
||||
<audio> schon.
|
||||
=================================================================== */
|
||||
const db4 = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
const tonId = db4.prepare(
|
||||
"SELECT id FROM chat_nachrichten WHERE anhang_art = 'ton' ORDER BY id DESC LIMIT 1").get()?.id;
|
||||
db4.close();
|
||||
ok(Number.isInteger(tonId),
|
||||
`die Sprachnachricht steht in der Datenbank (#${tonId}) — ohne sie misst unten nichts`);
|
||||
const tonWeg = await dogi.seite.evaluate(async (id) => {
|
||||
const voll = await fetch(`/workspace/api/chat/anhang/${id}`, { cache: "no-store" });
|
||||
const alles = new Uint8Array(await voll.arrayBuffer());
|
||||
const teil = await fetch(`/workspace/api/chat/anhang/${id}`,
|
||||
{ cache: "no-store", headers: { Range: "bytes=0-99" } });
|
||||
const stueck = new Uint8Array(await teil.arrayBuffer());
|
||||
return {
|
||||
bereiche: voll.headers.get("accept-ranges"),
|
||||
laenge: Number(voll.headers.get("content-length")),
|
||||
groesse: alles.length,
|
||||
status: teil.status,
|
||||
abschnitt: teil.headers.get("content-range"),
|
||||
teilBytes: stueck.length,
|
||||
gleich: [...stueck].every((w, i) => w === alles[i]),
|
||||
typ: voll.headers.get("content-type"),
|
||||
};
|
||||
}, tonId);
|
||||
ok(tonWeg.bereiche === "bytes" && tonWeg.laenge === tonWeg.groesse,
|
||||
`die Sprachnachricht kommt mit Accept-Ranges und Länge`
|
||||
+ ` (${tonWeg.bereiche}, ${tonWeg.laenge} von ${tonWeg.groesse})`);
|
||||
ok(tonWeg.status === 206 && tonWeg.teilBytes === 100 && tonWeg.gleich
|
||||
&& tonWeg.abschnitt === `bytes 0-99/${tonWeg.groesse}`,
|
||||
` und ein Abschnitt kommt als 206 mit genau diesen Bytes (${tonWeg.abschnitt})`
|
||||
+ " — ohne das spielt Safari gar nicht erst");
|
||||
|
||||
/* ---- DER AUSWEG, WENN DAS GERÄT DEN BEHÄLTER NICHT KANN ----------
|
||||
|
||||
Dass ein iPhone WebM nicht abspielt, lässt sich hier nicht
|
||||
herstellen -- Chromium kann es. Was sich herstellen lässt, ist
|
||||
GENAU DER ZUSTAND, in dem sich das Abspielgerät dann meldet:
|
||||
`error` mit Code 4 (MEDIA_ERR_SRC_NOT_SUPPORTED). Geprüft wird
|
||||
also der Rückfallweg, nicht das iPhone -- und das ist auch das,
|
||||
was hier kaputtgehen kann.
|
||||
|
||||
DIE ERSATZQUELLE IST EINE ECHTE DATEI VON DIESER SEITE, keine
|
||||
`data:`-Adresse: Die hat beim ersten Versuch die Inhaltsregel
|
||||
der Seite verletzt (`default-src 'self'`), und dann hätte ich
|
||||
gemessen, dass CSP greift -- nicht, dass der Behälter nicht
|
||||
passt. Zwei verschiedene Gründe für denselben Fehlercode. */
|
||||
const ausweg = await absichtlich([dogi], () => dogi.seite.evaluate(async () => {
|
||||
const g = document.querySelector(".chat-ton audio");
|
||||
if (!g) return { fehlt: "kein Abspielgerät in der Blase" };
|
||||
const kasten = g.closest(".chat-ton");
|
||||
g.src = "/workspace/assets/css/chat.css";
|
||||
g.load();
|
||||
await new Promise((r) => {
|
||||
g.addEventListener("error", r, { once: true });
|
||||
setTimeout(r, 4000);
|
||||
});
|
||||
await new Promise((r) => setTimeout(r, 50));
|
||||
const a = kasten.querySelector(".chat-ton__ausweg");
|
||||
return {
|
||||
kaputt: kasten.dataset.kaputt,
|
||||
code: g.error?.code,
|
||||
marke: kasten.querySelector(".chat-ton__marke")?.textContent.trim() || "",
|
||||
weg: a?.getAttribute("href") || "",
|
||||
wort: a?.textContent.trim() || "",
|
||||
vorlesewort: a?.getAttribute("aria-label") || "",
|
||||
hoch: a ? Math.round(a.getBoundingClientRect().height) : 0,
|
||||
geraetWeg: getComputedStyle(g).display === "none",
|
||||
};
|
||||
}));
|
||||
ok(ausweg.kaputt === "ja" && ausweg.code === 4,
|
||||
`ein Behälter, den der Browser nicht kann, meldet sich (Code ${ausweg.code})`);
|
||||
ok(/nicht abspielen/.test(ausweg.marke),
|
||||
` und der Satz sagt, woran es liegt: „${ausweg.marke}"`);
|
||||
/* „lässt sich GERADE nicht laden" hieße „gleich nochmal versuchen".
|
||||
Bei einem fremden Behälter hilft kein Versuch mehr. */
|
||||
ok(!/gerade/.test(ausweg.marke),
|
||||
" nicht mehr „gerade nicht laden“ — das war eine Vertröstung");
|
||||
ok(/\/workspace\/api\/chat\/anhang\/\d+\?laden=1$/.test(ausweg.weg),
|
||||
` daneben steht ein Weg zum Herunterladen (${ausweg.weg})`);
|
||||
ok(ausweg.wort === "Herunterladen" && /herunterladen/i.test(ausweg.vorlesewort),
|
||||
` beschriftet „${ausweg.wort}", für Vorleseprogramme „${ausweg.vorlesewort}"`);
|
||||
ok(ausweg.hoch >= 44, ` und mit ${ausweg.hoch} px hoch genug für einen Finger`);
|
||||
ok(ausweg.geraetWeg === true,
|
||||
" das stumme Abspielgerät ist weg — sonst stünde ein Schieber da, der nichts tut");
|
||||
|
||||
/* Die Seite wird wiederhergestellt: Oben wurde absichtlich eine
|
||||
kaputte Quelle eingesetzt, und ein nachfolgender Abschnitt soll
|
||||
keinen Zustand erben, den diese Messung hinterlassen hat. */
|
||||
await dogi.seite.reload({ waitUntil: "domcontentloaded" });
|
||||
}
|
||||
|
||||
/* =======================================================================
|
||||
|
||||
Reference in New Issue
Block a user