dulwich-users team mailing list archive

[Dave Borowitz <dborowitz@xxxxxxxxxx>]

On Tue, Mar 1, 2011 at 13:27, David Blewett <david@xxxxxxxxxxxxxxxx> wrote:

> On Mon, Feb 28, 2011 at 6:31 PM, Dave Borowitz <dborowitz@xxxxxxxxxx>
> wrote:
> > I can't tell for sure, but this traceback looks like what happens when
> the
> > git client decides its POST data is large enough to gzip, which is not
> > handled transparently by the wsgiref server. I happen to be using a
> server
> > that does handle it transparently, which is why I haven't been bugged by
> > this enough to fix it.
> > In these cases I usually find it helpful to sniff the wire protocol with
> > Wireshark or similar. To test if my guess is correct, you could also run
> git
> > with GIT_CURL_VERBOSE=1 and look for a Content-Encoding: gzip header.
> > Hope this helps.
>
> Indeed, that was the problem. I looked around and couldn't find a way
> to disable this behavior in Git,


Last I checked it was hard-coded over a certain (also hard-coded) threshold,
unfortuantely.


> so it seems like something that
> either needs to be handled at the Dulwich WSGI app layer (since we
> know git is going to try this), or via a WSGI middleware that will
> transparently decompress incoming requests before handing it off to
> Dulwich? The latter seems more appealing,


I agree.


> but I couldn't find any such
> in a cursory look last night.
>

I haven't even done that :). I would not be opposed to rolling our own, both
because it doesn't seem very complicated and because Jelmer doesn't like
adding required third-party dependencies.


> Thanks,
>
> David Blewett
>