Re: fou4s update checking problems

/ 2004-12-07 14:26:19 +0100
\ [email protected]:
> On Wed, Dec 08, 2004 at 02:15:25AM +1300, Lars Ellenberg wrote:
> > / 2004-12-07 13:41:09 +0100
> > \ Markus Gaugusch:
> > > On Dec 7, [email protected] <[email protected]> wrote:
> > > 
> > > >On Tue, Dec 07, 2004 at 12:37:13PM +0100, Bjorn Tore Sund wrote:
> > > >>
> > > >>On Tue, 7 Dec 2004, Markus Gaugusch wrote:
> > > >>
> > > >>>>Lars, it seems you changed download servers? Problem is the new server
> > > >>>>is Apache 2 and the same problem I reported back in April now hits any
> > > >>>>fou4s update checks
> > > >>>No, Lars probably didn't, but I did. Fou4s.gaugusch.at is now running
> > > >>>apache2 since a week or so.
> > > >>
> > > >>... and I can confirm that this problem appears with apache2,
> > > >>specifically.  But the downloads and patching works fine in
> > > >>my case, it's just that fou4s becomes very noisy.  I haven't
> > > >>been able to find a config setting on apache2 that fixes the
> > > >>issue.
> > > >
> > > >Which apache2 version, and on which version of the distribution?
> > > I'm using the default apache of SuSE 9.1 for fou4s.gaugusch.at.
> > > Apache2 2.0.49.
> > > 
> > > Is anyone of you using a proxy? I'm using a transparent squid setup or no 
> > > proxy and have no problem at all.
> > > Does it only happen on the console only? Or also in cronjob?
> > 
> > there is this readhat bugzilla entry
> > which may or may not be the same thing:
> >  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88575
> > which in turn refers to the "official apache2 CVS patch 1.463"
> >  http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/http/http_protocol.c.diff?r1=1.462&r2=1.463
> 
> You refer to a bug that has been fixed more than 2 years ago...

right...
and it even had slightly different symptoms than the issue at hand.
unfortunately it was the only seemingly related thing I found googling.
I meant to suggest that there may be something similar still in
some other code path.  To give an idea what to look for.

anyways, even though I currently cannot reproduce the problem, I suggest
the root of the problem (difference in the http response of apache 1 to apache 2,
see http://gaugusch.at/archives/fou4s-devel/2004-April/000270.html ) is this:

 [ I refer to SuSE 9.2 apache2-2.0.50-7.src.rpm ]


in httpd-2.0.50/modules/http/http_protocol.c,

AP_CORE_DECLARE_NONSTD(apr_status_t) ap_byterange_filter(ap_filter_t *f,
                                                         apr_bucket_brigade *bb)
{
...
line 2931 ff:
    while ((current = ap_getword(r->pool, &r->range, ','))
           && (rv = parse_byterange(current, clength, &range_start,
                                    &range_end))) {
        apr_bucket *e2;
        apr_bucket *ec;

        if (rv == -1) {
            continue;
|
| this is the case if the file is already fully retrieved
|
        }

        /* these calls to apr_brigade_partition() should theoretically
         * never fail because of the above call to apr_brigade_length(),
         * but what the heck, we'll check for an error anyway */
        if ((rv = apr_brigade_partition(bb, range_start, &ec)) != APR_SUCCESS) {
            ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r,
                          PARTITION_ERR_FMT, range_start, clength);
            continue;
        }
        if ((rv = apr_brigade_partition(bb, range_end+1, &e2)) != APR_SUCCESS) {
            ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r,
                          PARTITION_ERR_FMT, range_end+1, clength);
            continue;
        }

        found = 1;

        /* For single range requests, we must produce Content-Range header.
         * Otherwise, we need to produce the multipart boundaries.
         */
        if (ctx->num_ranges == 1) {
|
| so this is never reached 
|
            apr_table_setn(r->headers_out, "Content-Range",
                           apr_psprintf(r->pool, "bytes " BYTERANGE_FMT,
                                        range_start, range_end, clength));
        }
        else {
	...
    }

    if (found == 0) {
        ap_remove_output_filter(f);
        r->status = HTTP_OK;
        /* bsend is assumed to be empty if we get here. */
        e = ap_bucket_error_create(HTTP_RANGE_NOT_SATISFIABLE, NULL,
                                   r->pool, c->bucket_alloc);
        APR_BRIGADE_INSERT_TAIL(bsend, e);
        e = apr_bucket_eos_create(c->bucket_alloc);
        APR_BRIGADE_INSERT_TAIL(bsend, e);
        return ap_pass_brigade(f->next, bsend);
    }

an so the response contains only the HTTP_RANGE_NOT_SATISFIABLE,
but not the
  <Accept-Ranges: bytes
  <Content-Length: 0
  <Content-Range: bytes */1716
headers as with apache 1 (see that post from April above).

It may be enough to (almost) unconditionally sent those three header
lines. though I'm not sure about the RFC here -- it seems to be what
wget expects.

Someone able to reproduce the initial problem should try whether a copy
of those Content-Range header producing code into the (found == 0)
branch helps.

  Cheers,
	lge


	lge
--