Store filer

Dit problem lyder til at være relateret til serveren og ikke til programmering med .NET frameworket.

Derfor tror jeg du har ramt en forkert gruppe

Ja, det er muligt du synes det, men .Net frameworket er dog den eneste platform, hvor det er muligt at skrue på disse ting - maxRequestLength f.eks.

Det har altså derfor også relevans for denne gruppe, hvor jeg troede det ypperste inden for fornuftige svar var at finde.

Jeg har været på internationale sider, hvor det samme spørgsmål er stillet både til .net'tere og til IIS "eksperter", men desværre uden held hidtil.

Okay, det kan godt være det bare er mig der ikke forstår dit spørgsmål så:

1. Hvad uploader du og over hvilken protokol
2. Hvad sender filen afsted fra klienten og hvad modtager den på serveren

Det er i princippet alle filer, som kan uploades til serveren med input type=file og som modtages som HttpPostedFile.

Er lavet på en intranet, og når man sidder på lokalnettet er der ingen problemer heller ikke når filen har en størrelse på de 12MB, som jeg har tilladt i web.config.

Men når brugerne benytter siden hjemmefra går det altså galt, også selv om jeg har sat executionTimeout til en helt uhyrlig stor værdi.

Det ser som sagt ud til, at at selve uploadet virker, i hvert tilfælde arbejder routeren på højtryk, men når trafikken ophører så afsluttes der med en "Side ikke fundet"-fejl (ikke den rigtige .net fejl side, men mere én som ligner gammeldags asp-fejlmeldinger).

Jeg tror, at det har noget med en timeout at gøre, for jo langsommere forbindelse man har, des mindre størrelse på filen lykkes det at uploade.

Okay, der kan man bare se vi snakker om ASP.NET og upload fra en hjemmeside. .NET frameworket er meget mere end ASP.NET og derfor bliver man altså nødt til at forklare sig lidt tydeligere.

Har du tjekket at der ikke er sat en maxRequestLength i HttpRuntime taget i din machine.config som vil gøre at din web.config maxRequestLength bliver ignoreret.

Tjek evt. også hvad executionTimeout i HttpRuntime er sat til.

I machine.config er værdierne sat til:

executionTimeout="840"
maxRequestLength="12288"
useFullyQualifiedRedirectUrl="false"
minFreeThreads="8"
minLocalRequestFreeThreads="4"
appRequestQueueLimit="100"

Men alligevel fremkommer samme fejl.

12288 Bytes er ikke nok til en 12 MB fil, du skal huske at 1MB ~ 1024 Bytes
og at der også skal være plads til det af requestet der ikke er en del af filen.

Prøv evt. at lave et tjek ala dette:

If(minFil.PostedFile.ContentLength > 12288){
        lblFejlbesked.Text = "Din fil er større end 12288 bytes"
}else{
        //Gem filen
}

Okay, det har jeg prøvet, men den fejler alligevel. Der er heller ikke noget problem problem, når den selv samme fil skal uploades fra lokalnettet.

Og du får ikke fejlen i din label?

Så er det i IIS'en eller evt. et sted på netværket der er sat en grænse for at undgå belastning.

Okay, jeg må kigge andet steds efter en løsning. Men tak for hjælpen aligevel, Jakob.

Det var så lidt.

PS: Hvor kender du mit navn fra?

Fra activedeveloper såmænd :-)

Nååh.. Okay

Hej

Du mangler at sætte responseDeadlockInterval til samme høje værdi som executionTimeout. Men det løser ikke et helt andet og grundlæggende problem; din server vil forbruge mere end filens størrelse i ram under upload, og ikke frigive alt ram igen, pga hvad der ligner en memory leak fejl.
4. post i denne tråd fortæller om dette:
http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=95255

Jeg har selv arbejdet på dette problem i månedsvis, og i øjeblikket tæt på en løsning. Som du også selv har erfaret, kan problemet ikke løses ved at checke ContentLength, som moonduck foreslår. Upload'en skal gribes på et langt tidligere stadie, hvilket kræver roderi med frameworkets HttpWorkerRequest. Vi er nogle stykker der diskuterer problemet på følgende tråd (mit alias er ups101):

http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=99907

MVH

Hej Rasmus

Mange tak, jeg vil følge det videre forløb i diskussionen om dette basale problem - man skulle da næsten synes, at .net teamet kunne komme op med en løsning.

Hilsen Kurt

Det er også mit håb :-)