On Wed, Jul 10, 2013 at 9:57 PM, Greg Stein gst...@gmail.com wrote:
On Wed, Jul 10, 2013 at 6:57 PM, Ben Reser b...@reser.org wrote:
I have about 160ms of latency to this server. Mostly because I'm on
the west coast of the US and it's in the UK someplace based on it's
domain name.
Human
On 11.07.2013 19:42, Ben Reser wrote:
Now part of the concern over CL is that we'd end up having to use temp
files. My test setup was using ramdisk for the test workspace and the
system disk is a SSD, so that might help hide some of that. Even more
importantly I believe the request needs to be
On Thu, Jul 11, 2013 at 10:48 AM, Branko Čibej br...@wandisco.com wrote:
I suspect that's completely irrelevant, since the probe issues OPTIONS
requests which are very small and should never spill to disk. The big
requests would be GET/PUT of large files and/or deltas, IIRC -- but
those
On 10.07.2013 05:43, Greg Stein wrote:
On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej br...@wandisco.com wrote:
On 09.07.2013 05:53, Greg Stein wrote:
...
For *this* project, that is absolutely the case. We have never said
let's work against any server anybody decides to implement. We write
On 10.07.2013 10:20, Branko Čibej wrote:
On 10.07.2013 05:43, Greg Stein wrote:
On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej br...@wandisco.com wrote:
On 09.07.2013 05:53, Greg Stein wrote:
...
For *this* project, that is absolutely the case. We have never said
let's work against any server
On Wed, Jul 10, 2013 at 10:41 AM, Branko Čibej br...@wandisco.com wrote:
On 10.07.2013 10:20, Branko Čibej wrote:
On 10.07.2013 05:43, Greg Stein wrote:
On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej br...@wandisco.com wrote:
On 09.07.2013 05:53, Greg Stein wrote:
...
For *this* project, that
On Tue, Jul 9, 2013 at 7:33 PM, Ben Reser b...@reser.org wrote:
On Tue, Jul 9, 2013 at 1:25 AM, Stefan Sperling s...@elego.de wrote:
On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote:
The option doesn't seem like a big barrier when you're applying it to
a handful of machines for
Johan Corveleyn jcor...@gmail.com writes:
Can someone explain again why ra_serf / serf can't just resend
requests, with C-L, whenever it has received a 411? So (after we know
it's HTTP/1.1) send every request optimistically assuming chunked
encoding, and fallback whenever we get a 411 (and
On Wed, Jul 10, 2013 at 1:24 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Johan Corveleyn jcor...@gmail.com writes:
Can someone explain again why ra_serf / serf can't just resend
requests, with C-L, whenever it has received a 411? So (after we know
it's HTTP/1.1) send every request
On Wed, Jul 10, 2013 at 7:50 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Wed, Jul 10, 2013 at 1:24 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Johan Corveleyn jcor...@gmail.com writes:
Can someone explain again why ra_serf / serf can't just resend
requests, with C-L, whenever it
On Wed, Jul 10, 2013 at 4:20 AM, Branko Čibej br...@wandisco.com wrote:
...
Taking the the client MAY ... literally, we're compliant ... but
there's something to be said about about following the spirit of the
spec as well as the letter.
You're the one debating compliance.
I wouldn't really
On Wed, Jul 10, 2013 at 7:45 AM, Greg Stein gst...@gmail.com wrote:
IOW, while I may agree with regression, I'm not sure that we should
impact 99+% in order to deal with it. I'm not sure it is a reasonable
tradeoff.
Providing some real world numbers.
I tested against:
On Wed, Jul 10, 2013 at 3:57 PM, Ben Reser b...@reser.org wrote:
LOG --diff: RTT*(1+(revisions*2) [It appears we make 2 connections
per revision to do the diff, ouch, I guess that explains why log
--diff is so slow already]
Err I mean we make 2 sessions.
For log --diff with make
On Wed, Jul 10, 2013 at 6:57 PM, Ben Reser b...@reser.org wrote:
...
I have about 160ms of latency to this server. Mostly because I'm on
the west coast of the US and it's in the UK someplace based on it's
domain name.
Human perception is right around the 250ms mark. User interface
designers
On Mon, Jul 8, 2013 at 8:53 PM, Greg Stein gst...@gmail.com wrote:
For *this* project, that is absolutely the case. We have never said let's
work against any server anybody decides to implement. We write to our
client, and our server, and third parties adapt to our changes.
But we have said
On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote:
The option doesn't seem like a big barrier when you're applying it to
a handful of machines for yourself. Scale that effort up to a user
base of 20,000 users and the option stops looking like a reasonable
response. Resolving the
-Original Message-
From: Ben Reser [mailto:b...@reser.org]
Sent: dinsdag 9 juli 2013 09:46
To: Greg Stein
Cc: kmradke; Subversion Development
Subject: Re: svn commit: r1495419 - in
/subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c
util.c
On Mon, Jul 8
On 07/09/2013 10:33 AM, Ben Reser wrote:
So we had a conversation on IRC this morning about solutions.
This is what several of us seemed to agree was a reasonable compromise:
Have a tri-state option called http-chunked-requests. It would have
three states:
auto = Run the extra OPTIONS request
On Tue, Jul 9, 2013 at 7:33 PM, Ben Reser b...@reser.org wrote:
On Tue, Jul 9, 2013 at 1:25 AM, Stefan Sperling s...@elego.de wrote:
On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote:
The option doesn't seem like a big barrier when you're applying it to
a handful of machines for
On 09.07.2013 05:53, Greg Stein wrote:
On Mon, Jul 8, 2013 at 9:52 PM, Ben Reser b...@reser.org
mailto:b...@reser.org wrote:
...
Greg's argument here mostly depends on the idea that Subversion is
built to work against mod_dav_svn and any proxy or implementation that
doesn't
On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej br...@wandisco.com wrote:
On 09.07.2013 05:53, Greg Stein wrote:
...
For *this* project, that is absolutely the case. We have never said
let's work against any server anybody decides to implement. We write
to our client, and our server, and third
First of all a bit of top posting here because I want to paint my
response to Greg and then ultimately Ivan's email with a bit of
background. In the process of preparing to do the 1.8.1 release I
spent quite a bit of time reviewing nominated changes. I'll admit I
hadn't paid too much attention
Heya ... I'm not going to repond point-by-point. Your email covers
everything quite well. I only have a couple issues, noted below:
On Mon, Jul 8, 2013 at 9:52 PM, Ben Reser b...@reser.org wrote:
...
Greg's argument here mostly depends on the idea that Subversion is
built to work against
On Mon, Jul 8, 2013 at 11:53 PM, Greg Stein gst...@gmail.com wrote:
...
So let's say you have a RTT of 500ms, that means your command is going
to be delayed by 4 seconds assuming 8 connections, it also means that
you're going to have a pretty bad time using Subversion anyway. Yes
that
On Sun, Jun 30, 2013 at 7:37 PM, kmra...@rockwellcollins.com wrote:
On Tue, Jun 25, 2013 at 3:11 PM, kmra...@rockwellcollins.com wrote:
I agree that force-http10 is not good name and semantic. Actually
these proxies is not busted: it's allowed to HTTP/1.1 proxies to
require
On Fri, Jul 5, 2013 at 11:00 AM, Ivan Zhakov i...@visualsvn.com wrote:
...
Serf-trunk now has serf_bucket_get_remaining() to get length of
request body since r2008. Attached patch enables this functionality in
ra_serf. Within this patch Content-Length will be send for every
request for no cost
Greg Stein gst...@gmail.com writes:
Could you try svn trunk? Set busted-proxy=yes in your config to enable
the new behavior.
Without the knob turned out, you should get a 411 error. As Stefan
pointed out, we may want to consider detecting 411 and providing a
better error message.
With the
On Tue, Jun 25, 2013 at 3:11 PM, kmra...@rockwellcollins.com wrote:
I agree that force-http10 is not good name and semantic. Actually
these proxies is not busted: it's allowed to HTTP/1.1 proxies to
require content-length if they want. And strictly speaking proxies
may
have different
Philip Martin philip.mar...@wandisco.com writes:
Suppose serf were to keep track of the number of outstanding requests
(it may already do that I haven't checked). Then if the number of
outstanding requests is zero when the 411 is received the downgrade to
HTTP/1.0 will be OK. Lots of client
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: vrijdag 28 juni 2013 17:18
To: Ivan Zhakov
Cc: Greg Stein; dev@subversion.apache.org
Subject: Re: svn commit: r1495419 - in
/subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c
Bert Huijben b...@qqmail.nl writes:
-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com]
Sent: vrijdag 28 juni 2013 17:18
To: Ivan Zhakov
Cc: Greg Stein; dev@subversion.apache.org
Subject: Re: svn commit: r1495419 - in
/subversion/trunk/subversion
Subject: Re: svn commit: r1495419 - in
/subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c
util.c
Philip Martin philip.mar...@wandisco.com writes:
Suppose serf were to keep track of the number of outstanding requests
(it may already do that I haven't checked
Lieven Govaerts svn...@mobsol.be writes:
It seems to be connected to mod_deflate. My server was loading
mod_deflate (but not setting up any filters) and the import works with
the client setting
http-compression = no
but fails with
http-compression = yes
Still investigating.
Philip Martin philip.mar...@wandisco.com writes:
Lieven Govaerts svn...@mobsol.be writes:
It seems to be connected to mod_deflate. My server was loading
mod_deflate (but not setting up any filters) and the import works with
the client setting
http-compression = no
but fails with
On Jun 28, 2013 11:17 AM, Philip Martin philip.mar...@wandisco.com
wrote:
Philip Martin philip.mar...@wandisco.com writes:
Suppose serf were to keep track of the number of outstanding requests
(it may already do that I haven't checked). Then if the number of
outstanding requests is zero
On Tue, Jun 25, 2013 at 3:11 PM, kmra...@rockwellcollins.com wrote:
I agree that force-http10 is not good name and semantic. Actually
these proxies is not busted: it's allowed to HTTP/1.1 proxies to
require content-length if they want. And strictly speaking proxies may
have different
On Fri, Jun 28, 2013 at 1:30 PM, Greg Stein gst...@gmail.com wrote:
On Jun 28, 2013 11:17 AM, Philip Martin philip.mar...@wandisco.com wrote:
Philip Martin philip.mar...@wandisco.com writes:
Suppose serf were to keep track of the number of outstanding requests
(it may already do
On Wed, Jun 26, 2013 at 12:36:22AM +0200, Lieven Govaerts wrote:
What you say is not correct, the reason has been explained earlier in
this thread:
http://svn.haxx.se/dev/archive-2013-06/0530.shtml
I'm OK with making the extra request conditional on a config knob.
However, as you said in the
On Sun, Jun 23, 2013 at 3:43 AM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 11:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
...
The fix seems to be pretty simple and could be safely backported (see
patch). The only problem that probably we cannot backport addition of
new
On Tue, Jun 25, 2013 at 4:15 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Sun, Jun 23, 2013 at 3:43 AM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 11:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
...
The fix seems to be pretty simple and could be safely backported (see
patch).
On 25.06.2013 15:37, Ivan Zhakov wrote:
On Tue, Jun 25, 2013 at 4:15 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Sun, Jun 23, 2013 at 3:43 AM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 11:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
...
The fix seems to be pretty simple and
On Tue, Jun 25, 2013 at 7:15 PM, Branko Čibej br...@wandisco.com wrote:
On 25.06.2013 15:37, Ivan Zhakov wrote:
On Tue, Jun 25, 2013 at 4:15 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Sun, Jun 23, 2013 at 3:43 AM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 11:36 AM, Ivan
Branko Čibej br...@wandisco.com writes:
I'm really not a fan of this config knob. Anyone who carries their
laptop around will effectively have to set this as the default, because
you never know when the next weird proxy will pop up in front of your
server. And disabling chunked requests by
On Tue, Jun 25, 2013 at 8:15 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Sun, Jun 23, 2013 at 3:43 AM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 11:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
...
The fix seems to be pretty simple and could be safely backported (see
patch).
On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Branko Čibej br...@wandisco.com writes:
I'm really not a fan of this config knob. Anyone who carries their
laptop around will effectively have to set this as the default, because
you never know when the next
I agree that force-http10 is not good name and semantic. Actually
these proxies is not busted: it's allowed to HTTP/1.1 proxies to
require content-length if they want. And strictly speaking proxies may
have different behavior for different requests.
From *our* standpoint, they are
On 25.06.2013 20:45, Greg Stein wrote:
To that end, I find r1496470 to be insufficient. We need the dynamic
stuff, and we need to fix the configuration option name. I'm happy to
work on these two pieces, if we have a bit of consensus.
We (that is, you and I) certainly do. Is that a quorum? :)
On Tue, Jun 25, 2013 at 09:15:59PM +0200, Branko Čibej wrote:
On 25.06.2013 20:45, Greg Stein wrote:
To that end, I find r1496470 to be insufficient. We need the dynamic
stuff, and we need to fix the configuration option name. I'm happy to
work on these two pieces, if we have a bit of
On Tue, Jun 25, 2013 at 8:45 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Branko Čibej br...@wandisco.com writes:
I'm really not a fan of this config knob. Anyone who carries their
laptop around will effectively have
On Tue, Jun 25, 2013 at 10:45 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Branko Čibej br...@wandisco.com writes:
I'm really not a fan of this config knob. Anyone who carries their
laptop around will effectively
On Tue, Jun 25, 2013 at 11:03 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Tue, Jun 25, 2013 at 10:45 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Branko Čibej br...@wandisco.com writes:
I'm really not a fan of this
On Tue, Jun 25, 2013 at 5:15 PM, Branko Čibej br...@wandisco.com wrote:
On 25.06.2013 15:37, Ivan Zhakov wrote:
On Tue, Jun 25, 2013 at 4:15 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Sun, Jun 23, 2013 at 3:43 AM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 11:36 AM, Ivan
On Wed, Jun 26, 2013 at 1:37 AM, Lieven Govaerts svn...@mobsol.be wrote:
On Tue, Jun 25, 2013 at 5:15 PM, Branko Čibej br...@wandisco.com wrote:
On 25.06.2013 15:37, Ivan Zhakov wrote:
On Tue, Jun 25, 2013 at 4:15 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Sun, Jun 23, 2013 at 3:43 AM, Greg
Stefan Sperling wrote on Tue, Jun 25, 2013 at 22:19:30 +0200:
On Tue, Jun 25, 2013 at 09:15:59PM +0200, Branko Čibej wrote:
On 25.06.2013 20:45, Greg Stein wrote:
To that end, I find r1496470 to be insufficient. We need the dynamic
stuff, and we need to fix the configuration option name.
Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200:
On Tue, Jun 25, 2013 at 11:03 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Tue, Jun 25, 2013 at 10:45 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jun 25, 2013 at 11:55 AM, Philip Martin
philip.mar...@wandisco.com wrote:
On Wed, Jun 26, 2013 at 2:12 AM, Daniel Shahaf danie...@elego.de wrote:
Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200:
On Tue, Jun 25, 2013 at 11:03 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Tue, Jun 25, 2013 at 10:45 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jun 25,
Ivan Zhakov wrote on Wed, Jun 26, 2013 at 02:21:05 +0400:
On Wed, Jun 26, 2013 at 2:12 AM, Daniel Shahaf danie...@elego.de wrote:
Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200:
On Tue, Jun 25, 2013 at 11:03 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Tue, Jun 25, 2013 at
On Tue, Jun 25, 2013 at 6:21 PM, Ivan Zhakov i...@visualsvn.com wrote:
On Wed, Jun 26, 2013 at 2:12 AM, Daniel Shahaf danie...@elego.de wrote:
Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200:
...
The dynamic detection has a cost (1 extra request per connection),
that you might
On Wed, Jun 26, 2013 at 12:24 AM, Daniel Shahaf danie...@elego.de wrote:
Ivan Zhakov wrote on Wed, Jun 26, 2013 at 02:21:05 +0400:
On Wed, Jun 26, 2013 at 2:12 AM, Daniel Shahaf danie...@elego.de wrote:
Johan Corveleyn wrote on Tue, Jun 25, 2013 at 23:22:12 +0200:
On Tue, Jun 25, 2013 at
On 06/23/2013 07:47 PM, Greg Stein wrote:
On Sun, Jun 23, 2013 at 3:56 PM, Blair Zajac bl...@orcaware.com wrote:
On 6/22/13 1:22 AM, Lieven Govaerts wrote:
Even better if we could cache this info somewhere automatically. So
that the first time svn connects to a server ever it will use this
On Sat, Jun 22, 2013 at 07:39:23PM -0400, Greg Stein wrote:
The flag could be something like busted-proxy = on. When you start
seeing blog posts like In order to checkout from EXAMPLE.COM, you
must set busted-proxy=on in your .subversion configuration, and that
gets back to EXAMPLE.COM ... you
On Jun 23, 2013 4:54 AM, Daniel Shahaf danie...@apache.org wrote:
On Sat, Jun 22, 2013 at 07:39:23PM -0400, Greg Stein wrote:
The flag could be something like busted-proxy = on. When you start
seeing blog posts like In order to checkout from EXAMPLE.COM, you
must set busted-proxy=on in
On 6/22/13 1:22 AM, Lieven Govaerts wrote:
Even better if we could cache this info somewhere automatically. So
that the first time svn connects to a server ever it will use this
'slow' procedure, and then persists the results http/1.0 vs http/1.1
and chunked-encoding supported somewhere. Like we
If you really want to push, then proxy-hates-chunks could work well.
Oh man. Not proxy-blows-chunks? (SCNR.)
On Sun, Jun 23, 2013 at 7:35 PM, Peter Samuelson pe...@p12n.org wrote:
If you really want to push, then proxy-hates-chunks could work well.
Oh man. Not proxy-blows-chunks? (SCNR.)
LOL!
Actually, after an offlist email with Daniel, I would like to insist
on just calling it busted-proxy. We
On Sun, Jun 23, 2013 at 3:56 PM, Blair Zajac bl...@orcaware.com wrote:
On 6/22/13 1:22 AM, Lieven Govaerts wrote:
Even better if we could cache this info somewhere automatically. So
that the first time svn connects to a server ever it will use this
'slow' procedure, and then persists the
On Sat, Jun 22, 2013 at 9:08 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Ivan Zhakov i...@visualsvn.com writes:
Problem with this approach that some servers may support HTTP/1.1
partially. I.e. declare them as HTTP/1.1 but do not support chunked
Transfer-Encoding.
I wanted to avoid
On Sat, Jun 22, 2013 at 10:07 AM, Lieven Govaerts svn...@mobsol.be wrote:
On Sat, Jun 22, 2013 at 9:08 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Ivan Zhakov i...@visualsvn.com writes:
Problem with this approach that some servers may support HTTP/1.1
partially. I.e. declare them as
On Sat, Jun 22, 2013 at 10:24 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Sat, Jun 22, 2013 at 10:07 AM, Lieven Govaerts svn...@mobsol.be wrote:
On Sat, Jun 22, 2013 at 9:08 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Ivan Zhakov i...@visualsvn.com writes:
Problem with this
On Sat, Jun 22, 2013 at 11:12 AM, Lieven Govaerts svn...@mobsol.be wrote:
On Sat, Jun 22, 2013 at 10:24 AM, Johan Corveleyn jcor...@gmail.com wrote:
...
Maybe I'm missing something, but why would you downgrade to HTTP/1.0
only because of the 411 (Content Length Required)? Can't you just
On Sat, Jun 22, 2013 at 5:17 PM, Johan Corveleyn jcor...@gmail.com wrote:
On Sat, Jun 22, 2013 at 11:12 AM, Lieven Govaerts svn...@mobsol.be wrote:
On Sat, Jun 22, 2013 at 10:24 AM, Johan Corveleyn jcor...@gmail.com wrote:
...
Maybe I'm missing something, but why would you downgrade to
On Fri, Jun 21, 2013 at 11:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
...
The fix seems to be pretty simple and could be safely backported (see
patch). The only problem that probably we cannot backport addition of
new configuration option due our backward compatibility policy. But
may be I'm
This has been quoted before, but I'll repeat it again. RFC 2145, Section 2:
One consequence of these rules is that an HTTP/1.1 message sent to an
HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
constructed so that it remains a valid HTTP/1.0 message when all
headers not
On Fri, Jun 21, 2013 at 9:45 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Fri, Jun 21, 2013 at 9:19 AM, Greg Stein gst...@gmail.com wrote:
Please revert this. You *cannot* rely on a 411 response.
You are also not allowed to send a 1.1 request to a server for which
you don't know if they
On Fri, Jun 21, 2013 at 9:51 AM, Greg Stein gst...@gmail.com wrote:
...
But the answer is *not* to start a connection using 1.0.
1.1, of course. Start with 1.0, then upgrade.
On Fri, Jun 21, 2013 at 5:51 PM, Greg Stein gst...@gmail.com wrote:
On Fri, Jun 21, 2013 at 9:45 AM, Ivan Zhakov i...@visualsvn.com wrote:
On Fri, Jun 21, 2013 at 9:19 AM, Greg Stein gst...@gmail.com wrote:
Please revert this. You *cannot* rely on a 411 response.
You are also not allowed to
On Jun 21, 2013 10:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
Problem with this approach that some servers may support HTTP/1.1
partially. I.e. declare them as HTTP/1.1 but do not support chunked
Transfer-Encoding.
Then fix that problem. Add a flag saying busted_http11 and make it
On Fri, Jun 21, 2013 at 7:14 PM, Greg Stein gst...@gmail.com wrote:
On Jun 21, 2013 10:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
Problem with this approach that some servers may support HTTP/1.1
partially. I.e. declare them as HTTP/1.1 but do not support chunked
Transfer-Encoding.
On Jun 21, 2013 10:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
Problem with this approach that some servers may support HTTP/1.1
partially. I.e. declare them as HTTP/1.1 but do not support chunked
Transfer-Encoding.
Then fix that problem. Add a flag saying busted_http11 and
On Jun 21, 2013 10:36 AM, Ivan Zhakov i...@visualsvn.com wrote:
Problem with this approach that some servers may support HTTP/1.1
partially. I.e. declare them as HTTP/1.1 but do not support
chunked
Transfer-Encoding.
Then fix that problem. Add a flag saying
80 matches
Mail list logo
