[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#572276: instead of a test...



I'm not sure it's possible to modify that test case to reproduce it.
The point is that the behavior depends on whether the server sends the
final chunk in the same TCP packet as the real payload, or it wants to
send it in a separate one.  IOW whether the read() syscall returns the
final chunk together with the real data or not.

I'm attaching a small proxy in perl that I was trying to use when the
problem occurred.  Run the following command a few times, and I guess
you will get some "curl: (18) transfer closed with outstanding read data
remaining" errors:

curl http://127.0.0.1:1080/debian/dists/README

The commented push_filter is a workaround to disable sending the
content-length header in the proxy, which seems to fix the problem for
me.

Hope it helps.

#!/usr/bin/perl -w

use HTTP::Proxy;
use HTTP::Proxy::HeaderFilter::simple;
use strict;

my $port = 1080;
my $destination = 'ftp.fi.debian.org';

{
	package ForceNoContentLength;
	use base qw(HTTP::Proxy::BodyFilter);
        sub filter { 1; }
}

my $proxy = HTTP::Proxy->new(port => $port,
			     x_forwarded_for => 0,
			     via => '');
$proxy->logmask(HTTP::Proxy::ALL);
$proxy->push_filter(
	request => HTTP::Proxy::HeaderFilter::simple->new(
		sub {
			my ($self, $headers, $request) = @_;
			$request->uri->host($destination);
			$request->uri->port(80);
                        $headers->header(Host => $destination);
		}
	)
);
#$proxy->push_filter(response => ForceNoContentLength->new());
$proxy->start;

Reply to: