On Tue, Aug 25, 2009 at 12:40:05PM -0400, Daniel Richard G. wrote:
> On Tue, 2009 Aug 25 09:22+0100, Mark Hindley wrote:
> >
> > Could you try this patch
>
> Okay, so all files with errors (including 404s) are sent as body-less,
> "Content-Length: 0" responses.
>
> This does get rid of the timeouts for the 404 pages, which
> addresses thttpd's limitations; "apt-get update" works correctly
> now.
Good
> But what about servers that don't return Content-Length even
> for successful requests?
This is difficult. I don't think it can have happened really, as I
notice return_file() relies on Content-Length being set to initialise
$explen. It would blow up without that.
This is my solution. It isn't very elegant, but I think it covers the
issue.
> (By the way: What's with that weird patch format? patch(1) couldn't
> parse it. Is it a git-specific thing?)
It was derived from git. I edited the filenames by hand, though. Must
have cocked up. Sorry
diff --git a/apt-cacher b/apt-cacher
index f529ea4..23664dc 100755
--- a/apt-cacher
+++ b/apt-cacher
@@ -1344,7 +1344,7 @@ sub libcurl {
if (/^\r\n$/) { # Check for end
debug_message("libcurl reading of headers complete");
$response=HTTP::Response->parse($buf);
- &write_header(\$response) if defined $pkfdref;
+ &write_header(\$response) if (defined $pkfdref && defined
$response->content_length);
}
}
elsif ($pkfdref) {
@@ -1352,6 +1352,12 @@ sub libcurl {
data_feed(\$_);
}
}
+ if ($pkfdref && $response && !defined $response->content_length) {
+ # Must be HTTP 1.0 server upstream
+ info_message('Header output delayed whilst getting Content-Length');
+ $response->content_length(-s $$pkfdref);
+ &write_header(\$response);
+ }
unless ($response) {
info_message("Warning: failed to parse headers: $buf") if $buf;
$response=HTTP::Response->new(502);
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
