You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Tony Finch <do...@dotat.at> on 2000/11/01 00:00:04 UTC
Re: general/6711: byterange problems in 1.3.14
The following reply was made to PR general/6711; it has been noted by GNATS.
From: Tony Finch <do...@dotat.at>
To: new-httpd@apache.org
Cc: apbugs@apache.org
Subject: Re: general/6711: byterange problems in 1.3.14
Date: Tue, 31 Oct 2000 22:54:48 +0000
Joe Orton <jo...@light.plus.com> wrote:
>On Tue, Oct 31, 2000 at 10:30:40PM +0000, Tony Finch wrote:
>> The patch is broken. It introduces a new return value for
>> internal_byterange but it doesn't change all the code that calls
>> internal_byterange (directly or indirectly) to accommodate the change.
>> e.g. default_handler calls ap_each_byterange assuming that the return
>> value is boolean; ap_each_byterange is a wrapper around
>> internal_byterange which does not return a boolean.
>
>I tried to cover this properly, as per the comment in
>internal_byternage: the new return code is only used when realreq=0 is
>passed in, i.e., only in the call from ap_set_byterange.
>ap_each_byterange passes realreq=1 in, so the -1 will never get
>returned... what am I missing?
You are right -- I missed that. I'm looking at parse_byterange now
because I think that may be the culprit.
Tony.
--
en oeccget g mtcaa f.a.n.finch
v spdlkishrhtewe y dot@dotat.at
eatp o v eiti i d. fanf@covalent.net
Re: general/6711: byterange problems in 1.3.14
Posted by Joe Orton <jo...@redhat.com>.
On Thu, 2 Nov 2000, Tony Finch wrote:
> Joe Orton <jo...@light.plus.com> wrote:
...
> >I'm not sure I see the point of that: currently, in the failure case,
> >r->byterange comes out as 0, since it's never set before the error
> >return. That just sets it to 2 and then sets it back to 0 again.
>
> Because internal_byterange depends on the value of r->byterange when
> deciding what to add up. When you moved the assignment to r->byterange
> you changed the behaviour.
Argh! I'm with you, sorry, yes I messed up, your fix makes perfect sense.
Regards,
joe
Re: general/6711: byterange problems in 1.3.14
Posted by Tony Finch <do...@dotat.at>.
Joe Orton <jo...@light.plus.com> wrote:
>On Wed, Nov 01, 2000 at 12:17:06AM +0000, Tony Finch wrote:
>...
>> There's another bit of Joe's patch that I don't understand -- it seems
>> to break calculation of the content-length. Fixing this doesn't seem
>> to fix the problem, however.
>
>The content-length calculated in ap_set_byternage is the *total*
>content-length of the multipart response, if that's what you're talking
>about... this should only be used in the success case, where the 206 is
>being returned.
Gah, I need to do more standard-reading...
>I'm not sure I see the point of that: currently, in the failure case,
>r->byterange comes out as 0, since it's never set before the error
>return. That just sets it to 2 and then sets it back to 0 again.
Because internal_byterange depends on the value of r->byterange when
deciding what to add up. When you moved the assignment to r->byterange
you changed the behaviour.
Tony.
--
en oeccget g mtcaa f.a.n.finch
v spdlkishrhtewe y dot@dotat.at
eatp o v eiti i d. fanf@covalent.net
Re: general/6711: byterange problems in 1.3.14
Posted by Joe Orton <jo...@light.plus.com>.
On Wed, Nov 01, 2000 at 12:17:06AM +0000, Tony Finch wrote:
...
> There's another bit of Joe's patch that I don't understand -- it seems
> to break calculation of the content-length. Fixing this doesn't seem
> to fix the problem, however.
The content-length calculated in ap_set_byternage is the *total*
content-length of the multipart response, if that's what you're talking
about... this should only be used in the success case, where the 206 is
being returned.
> Index: http_protocol.c
> ===================================================================
> RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
> retrieving revision 1.291
> diff -u -r1.291 http_protocol.c
> --- http_protocol.c 2000/10/10 03:29:08 1.291
> +++ http_protocol.c 2000/11/01 00:15:02
> @@ -237,6 +269,7 @@
> long tlength = 0;
> int ret;
>
> + r->byterange = 2;
> r->boundary = ap_psprintf(r->pool, "%lx%lx",
> r->request_time, (long) getpid());
> do {
> @@ -245,11 +278,12 @@
> } while (ret == 1);
> /* If an error occured processing one of the range specs, we
> * must fail */
> - if (ret < 0)
> + if (ret < 0) {
> + r->byterange = 0;
> return 0;
> + }
> ap_table_setn(r->headers_out, "Content-Length",
> ap_psprintf(r->pool, "%ld", tlength));
> - r->byterange = 2;
> }
>
> r->status = PARTIAL_CONTENT;
I'm not sure I see the point of that: currently, in the failure case,
r->byterange comes out as 0, since it's never set before the error
return. That just sets it to 2 and then sets it back to 0 again.
joe
RE: general/6711: byterange problems in 1.3.14
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Joe Orton [mailto:joe@light.plus.com]
> Sent: Wednesday, November 01, 2000 2:17 AM
>
> On Wed, Nov 01, 2000 at 01:56:20AM +0000, Tony Finch wrote:
> > OK, I'll commit it if Greg/Joe or anyone else thinks my patch is
> > right. I'm still at a loss regarding the actual problem,
> though, and I
> > have caught some dread lurgy (probably on the plane) so I'm having
> > trouble thinking at the moment.
>
> I'd say back out my original patch, it's causing far more trouble than
> it's worth.
If you patch cleans up byte ranges to the spec, then I want to see
it remain. I'd rather BrowserMatch for non-compliant browsers and
provide a backwards thunk than leave it out of spec.
Re: general/6711: byterange problems in 1.3.14
Posted by Joe Orton <jo...@light.plus.com>.
On Wed, Nov 01, 2000 at 01:56:20AM +0000, Tony Finch wrote:
> OK, I'll commit it if Greg/Joe or anyone else thinks my patch is
> right. I'm still at a loss regarding the actual problem, though, and I
> have caught some dread lurgy (probably on the plane) so I'm having
> trouble thinking at the moment.
I'd say back out my original patch, it's causing far more trouble than
it's worth.
joe
Re: general/6711: byterange problems in 1.3.14
Posted by Tony Finch <do...@dotat.at>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>> From: Tony Finch [mailto:dot@dotat.at]
>> Sent: Tuesday, October 31, 2000 6:17 PM
>>
>> There's another bit of Joe's patch that I don't understand -- it seems
>> to break calculation of the content-length. Fixing this doesn't seem
>> to fix the problem, however.
>
>I saw that... notice the first 206 response size... quoting:
OK, I'll commit it if Greg/Joe or anyone else thinks my patch is
right. I'm still at a loss regarding the actual problem, though, and I
have caught some dread lurgy (probably on the plane) so I'm having
trouble thinking at the moment.
Tony.
--
en oeccget g mtcaa f.a.n.finch
v spdlkishrhtewe y dot@dotat.at
eatp o v eiti i d. fanf@covalent.net
RE: general/6711: byterange problems in 1.3.14
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: Tony Finch [mailto:dot@dotat.at]
> Sent: Tuesday, October 31, 2000 6:17 PM
>
> There's another bit of Joe's patch that I don't understand -- it seems
> to break calculation of the content-length. Fixing this doesn't seem
> to fix the problem, however.
I saw that... notice the first 206 response size... quoting:
Received: (qmail 45749 invoked from network); 31 Oct 2000 17:07:11 -0000
Message-Id: <20...@giganda.komkon.org>
Date: Tue, 31 Oct 2000 12:07:03 -0500 (EST)
From: Igor Roshchin <st...@giganda.komkon.org>
To: submit@bugz.apache.org
Cc: ache@freebsd.org, ports@freebsd.org
Subject: Apache consistently serving just a part of pdf file on the first request
>Number: 6770
>Category: general
>Synopsis: Apache consistently serving just a part of pdf file on the first request
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: apache
>State: closed
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Oct 31 09:11:43 PST 2000
>Closed-Date: Tue Oct 31 12:37:33 PST 2000
>Last-Modified: Tue Oct 31 12:37:33 PST 2000
>Originator:
>Release:
>Organization:
>Environment:
>Description:
Hello!
I have noticed that apache1.3.14 as built from the port collection on a
FreeBSD 3.5.1-RELEASE box has the following [mis]behavior:
When a .pdf file is requested, first just a small part of it is transferred
The log file shows two records
(both with a code of "206" and the amount of transferred bytes
smaller then the full size):
remote.host - - [31/Oct/2000:11:40:24 -0500] "GET /~user/cv.pdf HTTP/1.0" 206 12445
remote.host- - [31/Oct/2000:11:40:28 -0500] "GET /~user/cv.pdf HTTP/1.0" 206 1121
Netscape communicator (with an Acrobat plugin)
(4.75, an other 4.7x versions on winNT, MacOS-9,
and Irix) is used in all tests.
At times, on NT and on Mac the Netscape client was hanging completely.
When it is loading the file, first it is showing : xx% of FF kB,
where FF is the full file size, then it disappears, and
xx% of NN kB flashes,
where NN kB is the size that is smaller than the full file size,
and corresponds to the files logged in the access.log as mentioned above.
On the second request the file is usually served just alright.
I found that the same problems were reported to APACHE project
with the same problem while using MSIE.
(http://search.apache.org/) Reports #: 6711, 6715 6761, 6766)
After downgrading to 1.3.12 I found that there are no more problems
with this.
The Netscape shows similar indicator numbers as before,
and the log shows partial transfers (which I think correspond
to a partial pages, because the second set of message appeared after I
scrolled the pages in the document.
remote.host - - [31/Oct/2000:11:57:22 -0500] "GET /~igor/CV.pdf HTTP/1.0" 200 0
remote.host - - [31/Oct/2000:11:57:23 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 12444
remote.host - - [31/Oct/2000:11:57:27 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 1121
remote.host - - [31/Oct/2000:11:57:27 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 235
remote.host - - [31/Oct/2000:11:58:08 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 3748
remote.host - - [31/Oct/2000:11:58:09 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 4235
remote.host - - [31/Oct/2000:11:58:10 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 6116
remote.host - - [31/Oct/2000:11:58:13 -0500] "GET /~igor/CV.pdf HTTP/1.0" 206 1723
Regards,
Igor
Re: general/6711: byterange problems in 1.3.14
Posted by Tony Finch <do...@dotat.at>.
Tony Finch <do...@dotat.at> wrote:
>
> You are right -- I missed that. I'm looking at parse_byterange now
> because I think that may be the culprit.
Or maybe not. I think I am seeing the problem now but although IE
sometimes pauses for seconds when reloading the PDF file, the
transaction looks no different from my end of the connection *except*
that it seems to be associated with new connections -- keep-alive
connections are fast.
(Bah, why can't Windows close a TCP connection properly?)
There's another bit of Joe's patch that I don't understand -- it seems
to break calculation of the content-length. Fixing this doesn't seem
to fix the problem, however.
Tony.
--
en oeccget g mtcaa f.a.n.finch
v spdlkishrhtewe y dot@dotat.at
eatp o v eiti i d. fanf@covalent.net
Index: http_protocol.c
===================================================================
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.291
diff -u -r1.291 http_protocol.c
--- http_protocol.c 2000/10/10 03:29:08 1.291
+++ http_protocol.c 2000/11/01 00:15:02
@@ -237,6 +269,7 @@
long tlength = 0;
int ret;
+ r->byterange = 2;
r->boundary = ap_psprintf(r->pool, "%lx%lx",
r->request_time, (long) getpid());
do {
@@ -245,11 +278,12 @@
} while (ret == 1);
/* If an error occured processing one of the range specs, we
* must fail */
- if (ret < 0)
+ if (ret < 0) {
+ r->byterange = 0;
return 0;
+ }
ap_table_setn(r->headers_out, "Content-Length",
ap_psprintf(r->pool, "%ld", tlength));
- r->byterange = 2;
}
r->status = PARTIAL_CONTENT;