Return-Path: Delivered-To: apmail-apache-bugdb-archive@apache.org Received: (qmail 28977 invoked by uid 500); 2 Nov 2000 20:10:15 -0000 Mailing-List: contact apache-bugdb-help@apache.org; run by ezmlm Precedence: bulk Reply-To: apache-bugdb@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list apache-bugdb@apache.org Received: (qmail 28913 invoked by uid 501); 2 Nov 2000 20:10:04 -0000 Date: 2 Nov 2000 20:10:04 -0000 Message-ID: <20001102201004.28911.qmail@locus.apache.org> To: apache-bugdb@apache.org Cc: apache-bugdb@apache.org, From: Igor Roshchin Subject: Re: general/6770: Apache consistently serving just a part of pdf file on the first request Reply-To: Igor Roshchin The following reply was made to PR general/6770; it has been noted by GNATS. From: Igor Roshchin To: apbugs@apache.org, fanf@apache.org Cc: str@giganda.komkon.org Subject: Re: general/6770: Apache consistently serving just a part of pdf file on the first request Date: Thu, 2 Nov 2000 15:01:04 -0500 (EST) > Date: Thu, 2 Nov 2000 18:41:08 +0000 > From: Tony Finch > Subject: Re: general/6770: Apache consistently serving just a part of pdf file on the first request > > Igor Roshchin wrote: > > > >I regret you can not reproduce the problem. So many people > >are able to observe it on several different platforms > >(see my original message with the list of PRs related to this problem). > > I have been able to reproduce it now, but I have so far been unable to > work out what causes it. The slow requests look fast from the web > server end so I guess we are tickling a bug in the Acrobat plugin. > That's quite possible. I think, however I think I just found a bit, or to be more exact a byte that might be responsible for the misbehavior. Note, that the previous version (.12) of the server handles it just fine. I do not know what is the exact mechanism how the Acrobat plugin requests partial pages of the document . May be somebody, who knows the details of the pdf format and Acrobat plugin's API can find out what have changed in the server in this part. I suspect that there might be some error in the byte count of the information served during the second stage of the Acrobat plugin's request to the server (basically the request for the first page). I just compared the logs from the .14 server and .12 server, and I see that when the server is sending its response to the request for the 1st page (2nd stage of the request), there is a consistent 1 byte difference (for the same document) between the two versions of the server. Let me clarify what I call different stages: communication between the client and the server: (based on the web-server logs) 1. Request from the client - remote.host - - [02/Nov/2000:14:40:09 -0500] "GET /~user/cv.pdf HTTP/1.0" 200 0 2. 2nd stage: This is a response from .12 server. .14 sends 12444 bytes. remote.host - - [02/Nov/2000:14:40:10 -0500] "GET /~user/cv.pdf HTTP/1.0" 206 12445 remote.host - - [02/Nov/2000:14:40:14 -0500] "GET /~user/cv.pdf HTTP/1.0" 206 1121 remote.host - - [02/Nov/2000:14:40:15 -0500] "GET /~user/cv.pdf HTTP/1.0" 206 235 This was consistent for all logged attempts to retreive this file ( under different names to avoid any type of caching on both sides, because even with .14 server it works fine upon "reload" - unless the client is hung in the first place) Only on one occasion I saw that .14 server sent completely different (13xxx bytes) number of bytes. I am not certain what happened that time, but I think the client hung (on WinNT) I hope this helps, and somebody can compare the part of the server source responsible for this difference. Best, Igor