On Sat, Mar 5, 2011 at 6:24 PM, Dave Borowitz <[email protected]> wrote: > > On Mar 5, 2011 2:03 PM, "David Blewett" <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
