PHP-gesteuerter File-Upload als POST-Request... und dann 413

[Felix Riesterer]

Liebe Mitlesende,

heute scheitere ich an einem Datei-Upload, den ich aus einem PHP-Script heraus starten möchte. Das Ganze ist in Wirklichkeit "nur" ein POST-Request, der einen Parameter mit ca. 1,5MB posten soll.

Im Script verwende ich einen stream_context, bei dem ich folgende Parameter einsetze:

context params: Array
  (
    [options] => Array
    (
      [http] => Array
      (
        [method] => POST
        [timeout] => 20
        [header] => Array
        (
          [0] => Content-type: application/x-www-form-urlencoded
          [1] => Connection: close
          [2] => User-agent: geheim
          [3] => Content-Length: 1175075
        )
        [protocol_version] => 1.1
        [content] => db=VTJGc2RHVmtYMTlZS2JORmlxSVhLWEloWFFnVG ... (1.2MB)
      )
      [ssl] => Array
      (
        [SNI_enabled] => 1
        [SNI_server_name] => example.org
      )
    )
  )

Der Zielserver erlaubt POST-Daten bis zu 100MB Größe. Woher kommt dann mein 413er (Request Entity Too Large)? Auf meinem lokalen Testsystem erhalte ich keinen solchen Fehler! Im Fehler-Log steht (in etwa) das hier:

PHP Warning:  file_get_contents(https://example.org): failed to open stream: HTTP request failed! HTTP/1.1 413 Request Entity Too Large\r\n in /path/to/index.php on line 1951

Wer hat Ideen, die mir bei der Fehlersuche noch weiter helfen könnten?

Liebe Grüße,

Felix Riesterer.

[TS]

Hallo und guten Abend lieber Felix,

Liebe(r) alle,

Liebe Grüße,

Felix Riesterer.

fehlt da 'was?

Grüße
TS

[Felix Riesterer]

Lieber TS,

fehlt da 'was?

das kommt davon, wenn man eine Tag-Auswahl mit der Enter-Taste bestätigt. Ich wollte zuerst die Tags auswählen, bevor ich den Beitrag schreibe. Nun hat er den leeren Beitrag abgesandt... :-/ Aber zum Glück kann man hier inzwischen bearbeiten, wenn etwas sehr schief gegangen ist.

Liebe Grüße,

Felix Riesterer.

[Auge]

Hallo

fehlt da 'was?

das kommt davon, wenn man eine Tag-Auswahl mit der Enter-Taste bestätigt. Ich wollte zuerst die Tags auswählen, bevor ich den Beitrag schreibe. Nun hat er den leeren Beitrag abgesandt... :-/ Aber zum Glück kann man hier inzwischen bearbeiten, wenn etwas sehr schief gegangen ist.

Mach' dir nichts draus, du bist nicht der Erste, dem das passiert.

@Christian Kruse: Ist es sinnvoll, ein [ENTER] im Tageingabefeld abzufangen?

Tschö, Auge

[Christian Kruse]

Hallo Auge,

@Christian Kruse: Ist es sinnvoll, ein [ENTER] im Tageingabefeld abzufangen?

Ich muss mir erstmal ein Bild davon machen, was genau da passiert… denn so ganz leuchtet mir das noch nicht ein. Aber das erst heute Abend, nach Feierabend.

LG,
CK

[Der Martin]

Hi,

@Christian Kruse: Ist es sinnvoll, ein [ENTER] im Tageingabefeld abzufangen?

Ich muss mir erstmal ein Bild davon machen, was genau da passiert… denn so ganz leuchtet mir das noch nicht ein.

so wie ich das sehe, ist es das ganz normale Standard-Verhalten eines einzeiligen Eingabefelds in einem Formular: Da dieses Feld (im Gegensatz zu einem mehrzeiligen, aka textarea) die Enter-Taste nicht selbst verarbeitet, führt das zum Absenden des Formulars.

So long,
 Martin

[Christian Kruse]

Hallo Martin,

so wie ich das sehe, ist es das ganz normale Standard-Verhalten eines einzeiligen Eingabefelds in einem Formular: Da dieses Feld (im Gegensatz zu einem mehrzeiligen, aka textarea) die Enter-Taste nicht selbst verarbeitet, führt das zum Absenden des Formulars.

Soweit war ich auch, danke ;-) Die Frage ist eher, warum man dort auf die Idee kommt die Enter-Taste zu betätigen.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Die Frage ist eher, warum man dort auf die Idee kommt die Enter-Taste zu betätigen.

Weil man das bei einem select/option auch machen würde.

Bis demnächst
Matthias

[TS]

Hallo und guten Abend,

Der Zielserver erlaubt POST-Daten bis zu 100MB Größe. Woher kommt dann mein 413er (Request Entity Too Large)? Auf meinem lokalen Testsystem erhalte ich keinen solchen Fehler! Im Fehler-Log steht (in etwa) das hier:

PHP Warning:  file_get_contents(https://example.org): failed to open stream: HTTP request failed! HTTP/1.1 413 Request Entity Too Large\r\n in /path/to/index.php on line 1951

Wer hat Ideen, die mir bei der Fehlersuche noch weiter helfen könnten?

Wieso file_get_contents() und nicht file_put_contents() ?

Grüße
TS

[Felix Riesterer]

Lieber TS,

Wieso file_get_contents() und nicht file_put_contents() ?

weil ich gerne vom Server eine Antwort erhalten und sie ihm nicht vorschreiben möchte. Das POSTen erledigt der stream_context (dritter Parameter von file_get_contents).

Liebe Grüße,

Felix Riesterer.

[TS]

Hallo und guten Abend,

Wieso file_get_contents() und nicht file_put_contents() ?

weil ich gerne vom Server eine Antwort erhalten und sie ihm nicht vorschreiben möchte. Das POSTen erledigt der stream_context (dritter Parameter von file_get_contents).

Welche PHP-Version auf welchem OS?
Funktioniert es mit http, also ohne ssl?

Hast du es schon mal generisch versucht mit fsockopen()?
MMn kann man damit besser feststellen, an welcher Stelle es kneift.

Grüße
TS

[Felix Riesterer]

Lieber TS,

Welche PHP-Version auf welchem OS?

phpinfo()

Funktioniert es mit http, also ohne ssl?

Nein, da per .htaccess jeglicher http-Aufruf zu einem https-Aufruf umgeleitet wird. An der Umleitung scheitert es bereits, bevor ein http-Test einen 413er provozieren könnte.

Hast du es schon mal generisch versucht mit fsockopen()?

Wo sollte da ein Vorteil sein? Das Sicherheitsmodul (wie Jörg richtig recherchiert hatte) war offensichtlich die Ursache für den Fehler.

MMn kann man damit besser feststellen, an welcher Stelle es kneift.

MMn ist das Jacke wie Hose. Aber danke, dass Du Dir die Mühe gemacht hast, mögliche Ursachen zu finden!

Liebe Grüße,

Felix Riesterer.

[Felix Riesterer]

Ja, guter Support, der auch an einem Sonntag Abend um 21:30h binnen 10 Minuten auf eine Mail hin das Problem repariert (lag also nicht an meinem Script!), ist sein Geld wert!

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Ja, guter Support, der auch an einem Sonntag Abend um 21:30h binnen 10 Minuten auf eine Mail hin das Problem repariert (lag also nicht an meinem Script!), ist sein Geld wert!

Und die Ursache war? Ich vermute da einen vorgeschalteten FCGI-Mechanismus, denn der kann Requests begrenzen, noch bevor sie PHP zu Gesicht bekommt. Weiterhin kann auch der Apache selbst in Limit konfiguriert haben.

dedlfix.

[Felix Riesterer]

Lieber dedlfix,

Und die Ursache war?

ich habe festgestellt, dass die meine .htaccess um einige Zeilen ergänzt haben (ursprünglich war da nur ein Rewrite von http nach https):

<IfModule security2_module>
SecRuleEngine Off
SecRequestBodyAccess Off
</IfModule>

Kennst Du dieses Modul?

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

<IfModule security2_module>
SecRuleEngine Off
SecRequestBodyAccess Off
</IfModule>

Kennst Du dieses Modul?

Nee, ist mir bisher noch nicht übern Weg gelaufen. Sieht auf den ersten Blick so aus, als ob das Modul nun ganz abgeschaltet wurde. Was sicher auch nicht Sinn und Zweck von dessen Installation war.

dedlfix.

[Google weiß alles]

Sieht auf den ersten Blick so aus, als ob das Modul nun ganz abgeschaltet wurde. Was sicher auch nicht Sinn und Zweck von dessen Installation war.

Naja. Womöglich weil die Referenz bzw. Dokumentation von mod_security2 durchaus schwer aufzufinden ist. Hier übrigens die betroffene Einstellung "SecUploadFileLimit".

Die Links kann der Felix ja mal an den Hoster senden :-)

[Rolf b]

Hat sich dieser Fehler eigentlich im Apache-Log eindeutiger bemerkbar gemacht?

Rolf

[Felix Riesterer]

Lieber Rolf,

Hat sich dieser Fehler eigentlich im Apache-Log eindeutiger bemerkbar gemacht?

das muss ich erst einmal prüfen. Bei dieser "shared web hosting"-Lösung komme ich wahrscheinlich nicht an das Error-Log, sondern nur an das Access-Log. Mal sehen.

Liebe Grüße,

Felix Riesterer.

[Felix Riesterer]

Lieber Jörg,

Hier übrigens die betroffene Einstellung "SecUploadFileLimit".

ich sehe jetzt nicht, wo ich einen multipart-fileupload gemacht haben soll. Mein Script POSTet einfach einen Parameter "db=VTJGc2RHVmt...", ohne expliziten File-Upload (nix in $_FILE!). Ist Dein (übrigens super recherchiert!) Link also relevant?

Liebe Grüße,

Felix Riesterer.

[TS]

Hallo und guten Tag lieber Felix,

Hier übrigens die betroffene Einstellung "SecUploadFileLimit".

ich sehe jetzt nicht, wo ich einen multipart-fileupload gemacht haben soll. Mein Script POSTet einfach einen Parameter "db=VTJGc2RHVmt...", ohne expliziten File-Upload (nix in $_FILE!). Ist Dein (übrigens super recherchiert!) Link also relevant?

Sieh da! Hatte ich gar nicht drauf geachtet. Du hast ja ein normales Name-Value-Paar dazu vergewaltigt...

Die RFC für HTTP schreibt zwar keine Begrenzung für HTTP-Header vor, aber die meisten Webserver begrenzen diese aus Sicherheitsgründen und zur Vereinfachung der Programmierung:

LimitRequestLine für GET-Requests
LimitRequestFieldSize für POST-Requests

Außerdem sind die Header meistens noch gesamt begrenzt auf 4k (NGINX) oder 8k (Apache)

Darum hat man ja den MIME-SubType mutlipart/form-data eingeführt, um auch Streams entgegennehmen zu können.

Grüße
TS

[Felix Riesterer]

Lieber TS,

Du hast ja ein normales Name-Value-Paar dazu vergewaltigt...

richtig. Vergewaltigt. War einfacher zu "coden", als einen echten Upload mit multipart/form-data und dem ganzen Drumrum.

Die RFC für HTTP schreibt zwar keine Begrenzung für HTTP-Header vor, aber die meisten Webserver begrenzen diese aus Sicherheitsgründen

Das hatte ich mir schon fast gedacht. Jedoch wollte ich das Nachbilden eines "echten" Dateiuploads vermeiden. Auch habe ich noch nicht das nötige Tutorial dazu gefunden. Hättest Du da einen Link zur Hand? Alle bisherigen Treffer behandeln entweder das PHP-seitige Entgegennehmen eines Uploads, oder dass man bei kleinen Dateien ja "einfach POST verwenden" könne.

Verstehe mich bitte richtig: Falls meine Datei größer wird, komme ich sicher nicht um einen echten Upload herum. Daher wäre ich an einer richtigen Lösung sehr interessiert!

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Falls meine Datei größer wird, komme ich sicher nicht um einen echten Upload herum. Daher wäre ich an einer richtigen Lösung sehr interessiert!

Ich würde mich dazu bei bei den curl-Funktionen umschauen.

dedlfix.

[TS]

Hallo und guten Abend lieber Felix,

Verstehe mich bitte richtig: Falls meine Datei größer wird, komme ich sicher nicht um einen echten Upload herum. Daher wäre ich an einer richtigen Lösung sehr interessiert!

Das wirst Du vermutlich auch müssen, wenn die Request-Dat(ei)en größer werden. Ich vermute mal, dass es mit der Übergabe der Daten in den tieferen Schichten innerhalb der Webserver zu tun hat, ob die ganz billig auf dem "Stack" stattfindet oder auf dem "Heap". Ich benutze jetzt mal die Museumsbegriffe in der Hoffnung, dass Du mich verstehst.

So wie ich wieder längere Zeit am Schreibtisch sitzen kann^[1], könnte ich das mal zusammenstoppeln für Dich, allerdings dann generisch mit fsockopen() für SSL. Für "ohne" habe ich es schon in meinem Archiv. Ich habe auch schon diverse Tipps für die SSL-Variante gefunden im Netz - leider nicht in unserem Archiv :-(

Das passt ganz gut in den Monsterzyklus "Dateiupload mit PHP", an dessen Weiterentwicklung ich ja sowieso sitze.

BTW: Du hattest mal eine kleine JS-Animation erstellt, in der kleine Figuren über bestimmte Wege in einer Grafik geführt werden konnten und man dabei auf Eventtrigger treten konnte. Da war neulich ein Thread eines diner Berufskollegen, der ähnliches suchte. Leider warst Du wohl noch in den Ferien?

Grüße
TS

---

1. Hexenschuss der besonders giftigen Art :-( ↩︎

[Matthias Scharwies]

Servus!

So wie ich wieder längere Zeit am Schreibtisch sitzen kann^[1], könnte ich das mal zusammenstoppeln für Dich, allerdings dann generisch mit fsockopen() für SSL. Für "ohne" habe ich es schon in meinem Archiv. Ich habe auch schon diverse Tipps für die SSL-Variante gefunden im Netz - leider nicht in unserem Archiv :-(

@TS Gute Besserung!

Das passt ganz gut in den Monsterzyklus "Dateiupload mit PHP", an dessen Weiterentwicklung ich ja sowieso sitze.

Ich habe die Kommentare mal durch die {{ToDo}} - Vorlage vom Sachtext getrennt.

Wenn ein Artikel (zu) lang ist (Jetzt sind's schon ca. 50 Überschriften), könnte man ja mal überlegen, ihn in mehrere Unterseiten / eigene Artikel zu gliedern.

BTW: Du hattest mal eine kleine JS-Animation erstellt, in der kleine Figuren über bestimmte Wege in einer Grafik geführt werden konnten und man dabei auf Eventtrigger treten konnte. Da war neulich ein Thread eines diner Berufskollegen, der ähnliches suchte. Leider warst Du wohl noch in den Ferien?

Meinst du Browsergame: Mensch ärgere dich nicht!?

Herzliche Grüße

Matthias Scharwies

---

1. Hexenschuss der besonders giftigen Art :-( ↩︎

[TS]

Hallo und guten Tag Matthias,

Wenn ein Artikel (zu) lang ist (Jetzt sind's schon ca. 50 Überschriften), könnte man ja mal überlegen, ihn in mehrere Unterseiten / eigene Artikel zu gliedern.

Das überlegen wir schon länger. Man kann aber nur etwas aufteilen, was - zumindest in Ansätzen - vorhanden ist. Sonst gehen die Ideen dazu verloren.

Könntest Du mir dazu bitte einen Rumpfartikel "Apache-Tipps" einrichten, der dann auch gleich wieder aufgeteilt wird in "(Tipps für) Shared Hosting mit PHP", "Sicherheit (-> Fail2ban, IPtables, ...)", "Virtual Hosts", ".htaccess", "MIME-Type, Mod Rewrite, Content Negotiation, ...", usw.

Wir haben ja leider das Seminar "Umgang mit der Wikisoftware" nicht mehr geschafft...
Könnten wir dafür mal den vom mir schon mehrfach gewünschten (Weihnachten steht vor der Tür) Collaborating Server für virtuelle Klassenräume einrichten und benutzen?

Wie soll man das Wiki füllen, wenn man schon an der Hürde scheitert, wie die Software funktioniert?

Grüße
TS

[dedlfix]

Tach!

Könntest Du mir dazu bitte einen Rumpfartikel "Apache-Tipps" einrichten, der dann auch gleich wieder aufgeteilt wird in "(Tipps für) Shared Hosting mit PHP", "Sicherheit (-> Fail2ban, IPtables, ...)", "Virtual Hosts", ".htaccess", "MIME-Type, Mod Rewrite, Content Negotiation, ...", usw.

Das geht ganz schön weit weg von HTML & Co. (Ja, das gehen einige andere Artikel auch, die bereits im Wiki sind.) Es gibt da unter anderem die Seiten von Howtoforge. Dort geht man auf solche Konfigurationen und noch dazu nach Distributionen sortiert ein. Das sind schon sehr große Artikel, noch ohne dass da großartig der Schwerpunkt auf die Energie des Verstehens in den Texten gelegt wird. Ich hätte da große Bedenken, auch im Hinblick auf die notwendige spätere Pflege, solche Artikel bei uns im großen Stil zu erstellen. Du kannst aber jederzeit in deinem Benutzerraum anfangen und dann mal schauen, wie es sich entwickelt.

Wie soll man das Wiki füllen, wenn man schon an der Hürde scheitert, wie die Software funktioniert?

Wir verwenden Mediawiki, das ist ziemlich verbreitet und es sollte sich ausreichend allgemeine Dokumentation dazu finden lassen.

dedlfix.

[TS]

Hallo und guten Tag Dedlfix,

Das geht ganz schön weit weg von HTML & Co.

Von HTML vielleicht. Aber wer interessiert sich schon ausschließlich für HTML, wenn er Webseiten bauen will? Wir sollten durchaus mit den Möglichkeiten und an den Erfordernissen wachsen. Unser eigenes Archiv weist hier genügend Anregungungen, Fragen und Antworten aus, damit wir in Zukunft wieder ein abgerundetes Bild liefern können.

(Ja, das gehen einige andere Artikel auch, die bereits im Wiki sind.)

Leider wurde die Erstellung weiterer bisher nicht wirklich gefördert!

Es gibt da unter anderem die Seiten von Howtoforge.

Wer ist das? (scnr)

Das sind schon sehr große Artikel, noch ohne dass da großartig der Schwerpunkt auf die Energie des Verstehens in den Texten gelegt wird.

eben!

Ich hätte da große Bedenken, auch im Hinblick auf die notwendige spätere Pflege, solche Artikel bei uns im großen Stil zu erstellen. Du kannst aber jederzeit in deinem Benutzerraum anfangen und dann mal schauen, wie es sich entwickelt.

Sorry: Bla Bla!

Wiki heißt auch Wiki-Push und Collaboration, also Fragen, Ideen und Lösungen zusammenwirken zu lassen!

Wir müssen es endlich lernen, aus den dokumentierten Fragen auch sinnvolle und verständliche Antworten zu machen, anstatt immer nur zu penetrieren, dass man ja woanders hätte gucken können!

Ich vertrete diese Meinung hier seit ca. 1999, also seit ca. 17 Jahren Mitarbeit hier im Forum (mit kleinen Unterbrechungen). Und dazu stehe ich!

• Quellen-Hinweise -> JA
• Leser-Verweise -> NEIN

Wie soll man das Wiki füllen, wenn man schon an der Hürde scheitert, wie die Software funktioniert?

Wir verwenden Mediawiki, das ist ziemlich verbreitet und es sollte sich ausreichend allgemeine Dokumentation dazu finden lassen.

Das "wir verwenden" ist leider schon wieder ein "verpiss Dich, Du Ungebildeter!"

Ich hatte eigentlich angenommen, dass gerade Du hier bist, um Wissen zu teilen und dadurch neue Mitstreiter gewinnen zu können. Wenn ich dann bemängele, dass sich die Allgemeinheit mit "Mediawiki" und "Kramdown" äh "Markdown" nicht auskennt, dann empfinde ich das einfach als unverschämt, wenn Du mich wieder auf irgendwelche nicht näher bezeichneten Quellen im Internet verweist.

Der Fehler steckt im Marketing!

Das blöde Team vom Zuckerberg hat es besser verstanden, wieviel sie von ihren Usern abverlangen können, um erfolgreich zu werden, dafür haben sie sogar noch den "Daumen runter"-Button abgeschafft.

Also wehe, jemand klickt jetzt hier "[-]". Dann hetze ich ihm den Zuckermann oder wie der hieß auf den Hals.

Grüße
TS

[dedlfix]

Tach!

Wir verwenden Mediawiki, das ist ziemlich verbreitet und es sollte sich ausreichend allgemeine Dokumentation dazu finden lassen.

Das "wir verwenden" ist leider schon wieder ein "verpiss Dich, Du Ungebildeter!"

Nein, das heißt, dass ich kein Tutorial-Ersatz bin. Konkrete Fragen gern, aber ich schreibe keine Grundlagenartikel zur Bedienung von Standardsoftware. Die Syntax der Formatierungen ist in den Hilfeseiten ersichtlich, der Link dazu in der Nähe der Eingabebox. Zur Not geht im Wiki auch ein eingeschränkter Satz HTML-Elemente, wenn man die Wiki-Syntax nicht mag.

dedlfix.

[TS]

Hallo und guten Tag,

Wir verwenden Mediawiki, das ist ziemlich verbreitet und es sollte sich ausreichend allgemeine Dokumentation dazu finden lassen.

Das "wir verwenden" ist leider schon wieder ein "verpiss Dich, Du Ungebildeter!"

Nein, das heißt, dass ich kein Tutorial-Ersatz bin.

Das hat von Dir speziell ja auch niemand verlangt. Ich habe nur darum gebeten, einen virtiellen Klassenraum einzurichten, in dem dann von Zeit zu Zeit Veranstaltungen zum Thema stattfinden können.

Wir könnten also das versäumte "'Wie funktioniert das WIKI' Seminar" (@Gunnar: die Bindestriche bleibe ich schuldig) in regelmäßigen Abständen virtuell anbieten. Und wenn das dann technisch klappt, könnten die Virtuell-Seminar-Erprobten auch andere Themen anbieten.

Und bitte lass den Teilthread ins Meta-Forum umziehen :-)

Grüße
TS

[dedlfix]

Tach!

Das hat von Dir speziell ja auch niemand verlangt. Ich habe nur darum gebeten, einen virtiellen Klassenraum einzurichten, in dem dann von Zeit zu Zeit Veranstaltungen zum Thema stattfinden können.

Immer ruhig mit den jungen Pferden. Wir haben eine für kleinen Kreis ausreichende Vorgehensweise bestehend aus TeamSpeak (eigener Server) für die Unterhaltung und TeamViewer für die Präsentation von Bildschirminhalt. (Ja, TeamViewer bietet auch Tonübertragung, aber der TS war halt schon da und damit ist der TV auf Bild beschränkt.) An der Technik soll es nicht scheitern.

dedlfix.

[TS]

Hallo und guten Tag,

Immer ruhig mit den jungen Pferden. Wir haben eine für kleinen Kreis ausreichende Vorgehensweise bestehend aus TeamSpeak (eigener Server) für die Unterhaltung und TeamViewer für die Präsentation von Bildschirminhalt. (Ja, TeamViewer bietet auch Tonübertragung, aber der TS war halt schon da und damit ist der TV auf Bild beschränkt.) An der Technik soll es nicht scheitern.

Dann lass und das doch endlich mal angehen, dass alle Interessenten fit gemacht werden, um hier mitzuwirken. Für den Anfang würden ja ein paar Testsessions für die Macher im Monat reichen. Es kan ja nicht imner Jeder. Später könnte man dann über regelmäßige Sessions für alle Interessenten zum Aufbau von Themengruppen nachdenken.

Aber was wir nicht vorher am eignen Leib ausprobieren, können wir später auch nicht Anderen zum Lernen anbieten!

Grüße
TS

[Matthias Scharwies]

Servus!

Und bitte lass den Teilthread ins Meta-Forum umziehen :-)

Weiterdiskussion hier:

Meta: virtuelles Klassenzimmer

Herzliche Grüße

Matthias Scharwies

[Matthias Apsel]

Hallo TS,

Ich hätte da große Bedenken, auch im Hinblick auf die notwendige spätere Pflege, solche Artikel bei uns im großen Stil zu erstellen. Du kannst aber jederzeit in deinem Benutzerraum anfangen und dann mal schauen, wie es sich entwickelt.

Sorry: Bla Bla!

Wir haben das mehr als einmal erlebt, dass Leute mit großartigen Ideen kamen, alles umbauen wollten und kurz darauf wieder verschwanden. Oft haben dann @Matthias Scharwies, @dedlfix oder auch ich in nicht unerheblichen Maße Zeit investiert.^[1]

Wiki heißt auch Wiki-Push und Collaboration, also Fragen, Ideen und Lösungen zusammenwirken zu lassen!

Wiki heißt auch, im Benutzernamensraum zu beginnen.

Wir müssen es endlich lernen, aus den dokumentierten Fragen auch sinnvolle und verständliche Antworten zu machen

Sehr gern. Nimm dir eine dokumentierte Frage und mach in deinem BNR eine sinnvolle und verständliche Antwort draus. Wenn die fertig ist, packen wir die an eine passende Stelle der Dokumentation und können bei ähnlichen Fragen darauf verweisen. Das wäre hilfreich

Wie soll man das Wiki füllen, wenn man schon an der Hürde scheitert, wie die Software funktioniert?

Wir verwenden Mediawiki, das ist ziemlich verbreitet und es sollte sich ausreichend allgemeine Dokumentation dazu finden lassen.

Das "wir verwenden" ist leider schon wieder ein "verpiss Dich, Du Ungebildeter!"

Nein. Wenn du Probleme hast, frag nach. So groß können die aber bei dir nicht sein, denn schließlich gibt es genügend Bearbeitungen von dir.

Der Fehler steckt im Marketing!

Wie stellst du dir das Marketing vor?

Bis demnächst
Matthias

---

1. Die Diskussion um Iframes-Beispiel-Ansichten in den Artikeln selbst scheint sich auch dahingehend zu entwickeln. ↩︎

[Google weiß alles]

Ist Dein (übrigens super recherchiert!) Link also relevant?

1. Danke
2. Der Link ist schon relevant, allerdings nicht der Anker in Dokument, "SecUploadFileLimit" betrifft tatsächlich die Zahl der Files.

In Frage käme aber z.B. eine Nutzung der "Variable" 'ARGS_COMBINED_SIZE' und dass daraus eine Rolle ACL gebaut wurde. Um es zu wissen muss man sehen was da läuft. Für mich sieht es so aus, als habe man mod_security2 installiert und konfiguriert und weiß genau, dass die Einstellungen für viele Kunden zu eng sind. Dann wird für diese mod_security2 eben deaktiviert...

[Felix Riesterer]

Lieber dedlfix,

als ob das Modul nun ganz abgeschaltet wurde.

ja, das sehe ich genau so.

Was sicher auch nicht Sinn und Zweck von dessen Installation war.

Wenn der Kunde meckert, und wenn man Sonntag nachts um 21:30h quick&dirty helfen möchte, dann finde ich den gewählten Weg sehr sinnvoll. Der Support kann ja jetzt intern prüfen, was da im Einzelnen nicht geklappt hat, und das Problem dann möglicherweise "richtig" fixen. Bis dahin lebe ich als Kunde aber glücklich weiter. Und für meinen Hoster ist das sinnvollerweise ein wichtiges Ziel.

Liebe Grüße,

Felix Riesterer.