dulwich-users team mailing list archive

[David Blewett <david@xxxxxxxxxxxxxxxx>]

On Sat, Mar 5, 2011 at 6:24 PM, Dave Borowitz <dborowitz@xxxxxxxxxx> wrote:
>
> On Mar 5, 2011 2:03 PM, "David Blewett" <david@xxxxxxxxxxxxxxxx> wrote:
>> The relevant bits are in dulwich/web.py (GunzipFilter and
>> LengthLimitedInput). They both are implemented as simple WSGI
>> middleware apps that operate on wsgi.input. I had to retain the logic
>> in handle_service_request to ensure that wsgi.input was limited, as
>> tests in compat/ would start mysteriously hanging without it.
>
> Incidentally, that's why it's there. I don't have a computer handy so I
> haven't checked the full situation, but I think it goes something like this.
>
> During receive-pack, the PackStreamCopier is inflating a bunch of gzip
> streams. We don't know in advance how many delayed bytes there are, so we
> read 4k or so from the wire at once. Unfortunately, the wsgi.input object
> only supports read(n) calls with the semantics "block until exactly n bytes
> are read from the socket." LengthLimitedFile makes it so we don't block past
> the end of the file.

Makes sense. My concern was that it seems wrong for
handle_service_request to need to know this. It is handled in the
dul-web case because we wrap wsgi.input with the LengthLimitedInput
middleware, so everything works. Do the tests need to have similar
logic?

-- 
Thanks,

David Blewett