[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

From: <kmradke_at_rockwellcollins.com>
Date: Sun, 30 Jun 2013 10:37:22 -0500

> On Tue, Jun 25, 2013 at 3:11 PM, <kmradke_at_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
> > > have different behavior for different requests.
> >
> > From *our* standpoint, they are busted. Subversion wants to use
> > chunked requests. If they don't support it, then they are busted.
> > Simple as that.
> >
> > And we want to use a provocative name so that people understand
> > something needs to be *fixed*. Fixed for us because we view them as
> > *busted*.

> From the *users* standpoint subversion is busted. Something that
> I'm not seeing the point. Subversion will (now) work, but we still
> view the proxy as busted. It doesn't provide the performance
> characteristics that Subversion wants and expects. Note that
> Subversion is built to work against mod_dav_svn which is HTTP/1.1
> with chunked requests. The interposition of a proxy that disables
> chunked requests... busted.

Yes you missed my point. Users don't care why something is
broken, just that it is and that they now have to perform some
manual operation to get it to work again. Score a -1 for svn user
happiness. No reason to punish an user for something that is
most likely outside of their control.

> worked fine in 1.7 does not work in 1.8 without modifying potentially
> unrelated things that neither the server admin or the client
> user may have control over. (Think proxy at a hotel, etc.)
> Of course. But we can fix this. (and I believe, have fixed it)
> The spec states that 411 is an allowed response and is it also states
> the client should prefer to not use chunked requests if possible.
> Serf is being overly optimistic here.
> "Prefer" is not the same as "must" :-)

True, but it is there for the exact reason we are arguing about :)
(That clients which ignore this advice will not work correctly
 in a lot of real-world situations.)

> In our current model, we prefer chunked. But there is a pretty
> straightforward extension to serf's bucket model that should allow
> us to use C-L in many situations. We *might* be able to do that in a
> serf 1.x, but I'm not sure. Worst case, we'll add the feature in serf

I completely agree this is the preferred solution.

(Sorry for being so persistent about this. Just a pretty big sore
 spot at the moment because I've been implementing a subversion aware
 proxy. To be honest neon has been very easy to work with. Serf
 has been nothing but problematic. Old Serf versions were very
 easy to crash and get into infinite loops especially when dealing with
 proxy authentication. I feel bad I didn't have time to look into
 the problems until recently, especially since you are usually so quick
 to fix them - all problems I found were already fixed in later Serf
 versions than I was testing. I look forward to the latest 1.2.2 Serf
 changes since I think it should finally be stable enough to be supported
 in my expected non-utopia situations.)

Kevin R.
Received on 2013-06-30 17:38:09 CEST

This is an archived mail posted to the Subversion Dev mailing list.