A little more experimentation: On large files, I change the mime type to "application/save". The file downloads without a file ext (.pdf). When I rename the file to add .pdf, I can load the file with Adobe without problems.
Is the anyway to get the webserver (apache) to remember the file ext? Doug Doug Hale wrote: > As an experiment, I changed the mime type to "text/csv" so that my > browser would just same the file instead of trying to > get Adobe to open it. The file transfered fine. After changing it's ext > to .pdf, I opened it with Adobe and it opened with no problems. > > So it seems to be a client problem and not a server problem - actually > an embedded Adobe problem. > > So that is why I have been chasing my tail on the server!!!!! > > > Doug > > > Doug Hale wrote: > >> What happens is I get a message from Adobe Reader "The file is damaged >> and could not be repaired." >> It just quits sending data and everything stops normally - other that a >> truncated file. >> >> The limit seems to be about 26,000,000 bytes. >> >> AFAIK, a CGI model outputs its data to stdout, which the server(apache) >> streams into the TCP connection. >> TWebModule streams Response.ContentStream to stdout - it should not all >> be in memory at the same time. >> >> Doug >> >> >> Rob Kennedy wrote: >> >> >>> jumpsfromplanes wrote: >>> >>> >>> >>>> It is probably a Windows/memory problem. You just can't make file streams >>>> that big. >>>> >>>> >>>> >>> 20 MB? Of course you can. >>> >>> >>> >>> >>>> Your filestream code tries to swallow the entire PDF file whole into >>>> memory and *then* send it via HTTP to the client. >>>> >>>> >>>> >>> Doug's file-stream code doesn't do anything with the contents of the >>> file. Where do you see that? He opens the file and gives the stream to >>> the TWebResponse. TFileStream never caches the contents of the file. >>> >>> >>> >>> >>>> If you try to read a file that is too large, your filestream read code >>>> will fail. >>>> >>>> >>>> >>> Trying to allocate too much memory will yield an EOutOfMemory exception. >>> Has that happened in this case? >>> >>> >>> >>> >>>> You probably should use a small (16-64K) buffer and "loop" through the PDF >>>> file, one buffer load at a time. Send the buffer to the client and repeat. >>>> A small buffer created as a local variable will work fine. Using a buffer >>>> lets you work on files of any size - multiple gigabytes, if necessary. >>>> >>>> Remember that the last buffer load is probably only partially filled - you >>>> will have to count the number of actual bytes read into the buffer and >>>> make sure you only send that many to the client. Yeah, I know this is the >>>> old school way to do file transfers, but it actually works with (very) >>>> large files. >>>> >>>> >>>> >>> Notice that Doug didn't *write* any code for for copying the stream. Nor >>> should he. The SendStream methods of TApacheResponse and >>> TApacheTwoResponse copy the stream contents already. They use an 8 KB >>> buffer. >>> >>> >>> >>> >>>> I have a similar problem with a ^...@#&! web browser unit/component I use >>>> to spider an SSL-secured web site and download files. The guy that wrote >>>> the component also used TFileStream, and it bombs on files larger than >>>> about 20MB - great planning in this day and age of large files. I have a >>>> bunch of 2-4 GB files to download, so the component is useless to me until >>>> I get around to rewriting the idiot thing. :-( >>>> >>>> >>>> >>> You and Doug should be more specific about what happens when the file is >>> larger than 20 MB. Doug says the file "won't correctly transfer," and >>> you say you have a "similar problem." What's incorrect about the >>> transfer? How much gets sent? How much arrives? Does Apache log anything >>> about the request? Is the ContentLength header correct? >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.5.425 / Virus Database: 270.14.57/2492 - Release Date: 11/09/09 >>> 12:11:00 >>> >>> >>> >>> >> >> >> ------------------------------------ >> >> ----------------------------------------------------- >> Home page: http://groups.yahoo.com/group/delphi-en/ >> To unsubscribe: [email protected]! Groups Links >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.425 / Virus Database: 270.14.58/2493 - Release Date: 11/09/09 >> 19:40:00 >> >> >> > > > > > ------------------------------------ > > ----------------------------------------------------- > Home page: http://groups.yahoo.com/group/delphi-en/ > To unsubscribe: [email protected]! Groups Links > > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.425 / Virus Database: 270.14.58/2493 - Release Date: 11/09/09 > 19:40:00 > >
