On Tue, Mar 1, 2011 at 13:27, David Blewett <[email protected]> wrote:
> On Mon, Feb 28, 2011 at 6:31 PM, Dave Borowitz <[email protected]> > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
