Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Mel Smith" Newsgroups: comp.lang.javascript Subject: Re: .submit(....) problem Date: Sat, 1 Jun 2013 16:50:07 -0600 Lines: 46 Message-ID: References: <10nfa5ogfbi9n$.1bfhtk130g1fr.dlg@40tude.net> X-Trace: individual.net GkTr2RwT28EM85iEeuTiSQ9HnQE1ohCrCDFu62r57gGjo9/VtB Cancel-Lock: sha1:9hHGmWx6iW9pJM0/EksDEnezsLI= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: csiph.com comp.lang.javascript:20109 Denis said: > This probably falls over because your server starts sending the new page > before it has finished assembling it - as soon as the browser gets part > of the new page, it clears out the old one and starts to display what > it's received so far of the new one. Unfortunately No . I build the whole page (sometimes up to 382K) inside my CGI app. When it is completely assembled, I output it at once to my Apache 2.2.22 server. I will 'time' the building in my cgi app, and see how long it taks to receive, assemble, and send -- I'll let you know > >> Now, serendipitously, by using gzip (i.e., mod_deflate) in my >> Apache >> Server, this *does now* happen. > > That's probably because using compressed pages, your server doesn't start > the compression until the whole page/file is prepared, so it doesn't send > the page until it's been fully created. > > The more complete solution in your server side script might be not to > send any non-header content until you have finished preparing the page. As noted above, I follow the same procedure in my CGI server app, and when the page is built and complete, I output it to Apache where it is (assumedly) 'gzipped' and then is sent off to the client. So, I'm still perplexed. But, what I see on my client's screen (which is really *me* testing) is my final content I wish left in place, but displayed only for a split-second, then the screen reverting to the original screen, then a long wait, then the new screen displays. So, it is between the 'submit' and the reception that something happens to revert to the original screen during the wait process.. I'll have to take this to bed with me again and hope I get an inspiration. Thanks for the comment. -Mel