Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D0F4D17A7F for ; Wed, 1 Oct 2014 14:04:10 +0000 (UTC) Received: (qmail 76426 invoked by uid 500); 1 Oct 2014 14:04:10 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 76372 invoked by uid 500); 1 Oct 2014 14:04:10 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 76362 invoked by uid 99); 1 Oct 2014 14:04:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 14:04:10 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of philip.martin@wandisco.com designates 74.125.82.42 as permitted sender) Received: from [74.125.82.42] (HELO mail-wg0-f42.google.com) (74.125.82.42) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Oct 2014 14:04:05 +0000 Received: by mail-wg0-f42.google.com with SMTP id z12so551776wgg.25 for ; Wed, 01 Oct 2014 07:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=obByo2nrCYqvIt/wpFA8oTxLGrN2jaor+57or/Q6/6Q=; b=pGTpawo5D4wPiUl8c9fSD37RbTGnoyVbZQrpldTFj1kXmZshMTNeU+TxgM/J7afwjO gE5OAqhscNxewiuYO6hOrZYhzXZPl3ayUWgttTlo6O5sVzFb+LN+CTywt8J1BakhOWAY k75pWA92hLyIJwqeeYwa4VEvCHkuXsGcaMvrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=obByo2nrCYqvIt/wpFA8oTxLGrN2jaor+57or/Q6/6Q=; b=L/a1zY1vuRl+C9UvrMQ4PWpRpBHxpY+e1Cg2ODkdu6NCO3fOwADA7CnrfR4dJI+//e KOgAEeMP50Etz7cTLTowY0Ck8eAfYCI8cTDFUkhjLChAxbpP0Y0ryRPMmI2OeJFYt191 e4H/j85fD/fLXP971UStaZNhaCWhdCiMepxkkl0wI1OABroG0+RCHyr5xtdH92uaJ5jw ghbLmdVp800/XOldDeabFJJb7cBF+riTn9yj2+Bglyp69GC95ihX2sHM9ucWYNeIcc7x 6Wu8jokD8ZIgqTNDIP6z+jqoz1QqkdkjuQE6nPJDeNJupVVlmfnVB1h89/G+Uu++V+7e Pmpw== X-Gm-Message-State: ALoCoQnRVr5nIMNtb9w4b5M0eiP4eSxZlQOlzp+WP5dSmt5L7F66WTxV+OdvhV4Mbcy470Rguy1q X-Received: by 10.194.94.73 with SMTP id da9mr63601441wjb.67.1412172223406; Wed, 01 Oct 2014 07:03:43 -0700 (PDT) Received: from localhost (cpc20-farn7-2-0-cust13.6-2.cable.virginm.net. [86.15.228.14]) by mx.google.com with ESMTPSA id ky3sm1266393wjb.39.2014.10.01.07.03.42 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 01 Oct 2014 07:03:42 -0700 (PDT) From: Philip Martin To: "C. Michael Pilato" Cc: serf-dev@googlegroups.com, Andreas Stieger , dev@subversion.apache.org Subject: Re: [serf-dev] serf errors on responses bigger than 4GB References: <87sijeda7h.fsf@ntlworld.com> <5427CDF0.2010205@wandisco.com> <87k34mrbii.fsf@ntlworld.com> <5429A12F.9080306@wandisco.com> <542B068F.4030906@gmx.de> <87a95gkqux.fsf_-_@ntlworld.com> <542BFC6D.7000204@gmail.com> Date: Wed, 01 Oct 2014 15:03:42 +0100 In-Reply-To: <542BFC6D.7000204@gmail.com> (C. Michael Pilato's message of "Wed, 01 Oct 2014 09:06:53 -0400") Message-ID: <8761g3lwe9.fsf@ntlworld.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked by ClamAV on apache.org "C. Michael Pilato" writes: > The log message for r2419 mentions "files" larger than 4Gb, and leads me > to believe that this problem only affects GETs. But here, Philip avoids > the term "files" and talks about the "compressed size". Does the bug > fixed in r2419 manifest on any response > 4GB, such as a bulk-mode > REPORT carrying a whole Subversion tree that's larger than 4GB? I can trigger the decompression error on a 5GB REPORT by setting http-bulk-updates=yes on the client side. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*