Na dann... lager ich mal teile meines Workloads dahin aus . Gerade getestet, funktioniert einwandfrei.

Das escapen ist gar nicht schwierig? Auf diese Weise öffnest du (Mal wieder) nur Einfallstore für Schwachstellen

Kurze Frage, der Fehler klingt sehr stark nach fehlenden escapen der Eingabe, nimmst du etwa plumb die Eingabe des Nutzers?

Zitat von GM7

Das ist doch kein Meme

Es ist traurig ich weiß!

Stimmt, MIMO hab ich total vergessen, sehr guter Tipp

Das kann man mit einem Ticketsystem genau so ja auch umsetzen. Ob das jetzt mit osTicket so geht, weiß ich jedoch nicht.

Intern verwenden wir aktuell ja YouTrack

Zitat von Hanashi

Ja, dann musst du dir auch den eigentlichen Server anschauen, der hinter dem Proxy steckt.

Hab das jetzt mal kontrolliert und dort von 2MB auf 200MB rauf gegangen, bleibt leider dabei.
Hab client_max_body_size 200M; auch mal Testweise in alle Location Blöcke eingefügt, auch dem wo der Proxy definiert wird, keine Änderung jedoch .

osTicket | Support Ticketing System

so mit das bekannteste, gibt auch noch weitere

Sehe ich jetzt nichts, mir kommt aber eventuell was ein, könnte es daran liegen das NGINX nur ein Proxy ist?

location @octane {
        set $suffix "";

        if ($uri = /index.php) {
            set $suffix ?$query_string;
        }

        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header Scheme $scheme;
        proxy_set_header SERVER_PORT $server_port;
        proxy_set_header REMOTE_ADDR $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        proxy_pass http://127.0.0.1:9191$suffix;
    }

Später mal genauer schauen, ich gehe jetzt erstmal schlafen

Am Ende des http-Blocks bevor die Config-Files für die Seiten geladen wird.

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;
        server_tokens off;

        server_names_hash_bucket_size 128;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Zitat von Gustl

Schon mal über sftp versucht?

Wozu, es geht hier um NGINX, nicht SFTP.

Zitat von Gustl

Nutzt du php?

Das Backend ist Laravel ja.

Zitat von Gustl

Dann hast du vielleicht die php.ini vergessen.

Es geht weiterhin um NGIXN und nicht PHP, das ebenfalls 2GB annimmt.

Zitat von Gustl

Ansonsten in der nginx.conf die direktive client_max_body_size setzen / deklarieren

Zitat von Syntafin

das mein NGINX Server trotz einer erlaubten Body size von 2GB dieses ablehnt mit der Fehlermeldung Request Entity To Large.

Zitat von flyingtable07

Ich vermeide solch große Uploads immer generell.

Lässt sich bei Bildern nicht immer vermeiden bei gewissen Auflösungen.

Zitat von flyingtable07

Wie wärs wenn du die Datei in chunks hochlädst? Ein Client-side script, dass die datei in 1mb Blöcke unteteilt und diese dann einzelt hochläd. auf dem server kannst du die datei ganz einfach wieder zusammensetzen.

Es auf Frontend-Seite zu zerlegen und als Chunk hochzuladen ist zwar eine "Lösung", löst aber nicht das eigentliche Problem das NGINX trotz einer erlaubten größe bis 2GB schon bei 28mb streikt und das will ich ja gelöst haben.

Offtopic:
https://usenet-abc.de/wiki/Team/Vollquottel

Hallöchen,

gerade beim testen von größeren Uploads (Bild mit 30mb) gesehen, das mein NGINX Server trotz einer erlaubten Body size von 2GB dieses ablehnt mit der Fehlermeldung Request Entity To Large.

Jetzt stehe ich gerade natürlich ein wenig auf dem Schlauch, jemand eine Idee ob das noch von einer anderen Einstellung kommen kann die ich gerade nicht auf dem Schirm habe?

Zitat von Silas

Hi Akrep irgendwoher kommt mir dein name bekannt vor. Bist du noch in anderen Foren ?

KingKaSo, DrPinkelstein, D.W.H. und "neu" eben Akrep/Akreb

Nein, nutze solche Tools nicht, da ich dem Prinzip pro App ein eigener Server verfolge.

Update zum Upscaling

Wird also zum Glück fertig vor dem nächsten Pyro Zeitfenster.

Hier mal die 2 Aufrufe:

Habs als Gist gespeichert, da zu lange für hier.

Zitat von flyingtable07

xD

Dann bin ich mit 320ms ja noch gut dabei.

Wenn du siehst was das Datawarehouse da bastelt, wüsstest du wieso .

Zitat von flyingtable07

wofür sollte man eine solche qualität brauchen? Das ist mehr als jeder Kinofilm hat. Das frisst einfach nur Speicherplatz, so gut ist die KI auch nicht, dass sie da wirklich was machen kann.

Weil ichs kann? Ganz einfach ?

Zitat von flyingtable07

Wie lange sollte eurer Meinung nach eine Datenbankabfrage bei einer Guten Anwendung maximal dauernt? Von Benutzer Ineraktion bis Ergebnis Anzeige.

Millisekunden. Vielleicht hast Glück, und das hier ist nicht im Cache:

XIVData

A community driven database, progress tracker and crafting tool

dev.xivdata.com

Dann weißt was böse ist