Kann ich nicht bestätigen. Beweise Watson, Beweise.

p.s.: Zugelassen sind natürlich nur Clients, deren Verbeitungsgrad höher als "homöopatisch" und deren Fehlimplementierung mehr als nur bedauerliches Einzelschicksal ist

Mister Ad

CoverDB

Guten Tag,

kurz mal das warum erklärt.

Beim speichern der Bilder auf dem Server gibt es hin und wieder Probleme dadurch,
dass die Dateinamen aus dem Titel erzeugt werden.

Beispiel: Jackie Chan's Triologie wird gespeichert als jackie_chan_s_triologie(cover).jpg

Beim herunterladen, wird die Datei auch so dem User als Speichern unter angeboten.

Das sind zwei Sachen die ich nicht wollte, den Fehler und den doofen Dateinamen.
Also sollen die Bilder ab bald nur noch mit Nummern gespeichert werden (12341231.jpg zum Beipspiel) im Order httpdocs/www/cover/images/ und erst beim Download erhalten Sie wieder den korrekten Namen aber ohne unterstrieche und mit Sonderzeichen -> Jackie Chan's Triologie (Cover).jpg oder Jackie Chan's Triologie (Front).jpg

Bleibt nur noch das Zweite und ein neues Problem.

Problem 2
Wie kann ich den Download für ein Bild korrekt starten lassen, obwohl das Bild nicht auf dem selben Server ist? In Verbindung mit der Namensgebung beim starten des Downloads.

Beispiel: Die Seite ist auf http://www.coverdb.de/index.php und das Bild liegt auf http://cdb.denma.de/images/12313414.jpg

Problem 3 (neu)
Neu Bilder werden noch per Hand freigeschaltet, eben wegen den unregelmäßig auftretenden Fehlern. Will ich nun ein löschen, was wie oben im Beipiel nicht auf dem gleichen Server, geht das nicht. Er löscht den Eintrag in der DB, aber das Bild bleibt auf dem Server liegen.

Kann mir eine Idee geben, wie ich das hinbekomme?

MFG

Das ist unerheblich. Es erspart einem jede Menge sinnfreier Bastelei, wenn man gewisse Regeln bei der Namensbildung beherzigt.

Ja, und die lauten wie bereits ausgeführt:Da ist weder von url encoding noch von ascii-7 (oder gar einem subset davon) die Rede.
Ich warte noch auf praxisrelevante Gegenbeispiele. Beweise Watson, Beweise.
Bis dahin sind Deine "berechtigten Zweifel" nur persönliche Meinung und unerheblich. Daran ändert auch nichts, sie ohne Belege zu wiederholen.

Soll es aber für den client vollständig so aussehen, als ob die Daten vom ersten Server stammen?
Was kannst Du beim zweiten Server machen? Nur benutzten as-is oder auch Skripte installieren? Die Frage glt auch für Problem 3Weil Du da genau was tust?
Wofür gibt es die verschiedenen Server? Was ist deren Aufgabe? Was soll letztendlich erreicht werden? Was davon ist fest und was noch im Fluß/änderbar?

Du bist ein niedlicher Elch. <g>

Lern lesen.

Du lieferst immer noch keinen Beleg dafür, warum man nur das von Dir aufgespannte Subset von ascii-7 benutzen soll (oder darf?).
Mir kommt es bisher halt so vor: Du hast Blödsinn beim url encoding geschrieben (was ja kein Problem ist. Passiert mir in ähnlicher Form auch regelmäßig. Aber das jetzt folgende tue ich dann nicht), willst es nicht zugeben und hast deshalb weiteren Blödsinn nachgeschoben, um doch noch schlau zu wirken. Sowas kann ich nicht leiden, also halte ich dagegen. Dafür möchte ich mich beim OP entschuldigen. Wir müllen Deinen Thread zu, aber das hier will ich einfach nicht so unwidersprochen stehen lassen.

Lern richtig zitieren.
Ordentliche Quellenangabe und den gesamten relevanten Teil - nicht nur das sinnentstellende Fitzelchen, das Dir in den Kram passt.
Mir fehlt da auch der Bezug zu den vorherigen Ausagen.
Denn wenn ein Client nur den Standard (und deshalb dieses Feature nicht) imlementiert hat, dann ist es eben nicht da; also das gesamte Content-disposition-usw-usw. Dann hilft es auch nichts, wenn im Dateinamen nur a-z Zeichen standen. Und sollte ein einzelner den Zusatz zu http implementiert haben, aber anders als alle anderen und anders als im rfc beschrieben, dann ist das besagtes bedauerliches Einzelschicksal und für die Praxis egal. Fazit: Netter Hinweis, aber leider hier irrelevant. Und wir wollen ja nicht vom Thema ablenken.