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, 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, but I couldn't find any such in a cursory look last night. 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
