dulwich-users team mailing list archive

[Dave Borowitz <dborowitz@xxxxxxxxxx>]

On Mar 5, 2011 2:03 PM, "David Blewett" <david@xxxxxxxxxxxxxxxx> wrote:
>
> Attached is a patch that allows the WSGI server to transparently
> decompress incoming requests that use Content-Encoding: gzip. With
> this patch, I can now serve the dulwich git repo with dul-web and
> successfully clone it with c git.
>
> 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.

> I added a GunzipTestCase as well, and in so doing restructured
> HTTPGitApplicationTestCase to be able to share some of its logic for
> setting up a simple scenario.
>
> --
> Thanks,
>
> David Blewett
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dulwich-users
> Post to     : dulwich-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dulwich-users
> More help   : https://help.launchpad.net/ListHelp
>