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 > >
