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

Re: Tri-state for http-detect-chunking config option

From: Daniel Shahaf <danielsh_at_apache.org>
Date: Fri, 12 Jul 2013 02:51:37 +0000

On Thu, Jul 11, 2013 at 10:15:34PM -0400, Greg Stein wrote:
> The tri-state switches this to:
>
> = auto / default: send an extra OPTIONS. like "on" above.
>
> = yes: no delivery of OPTIONS. presume chunked is allowed.
>
> = no: no delivery of OPTIONS. only use C-L, as chunked is presumed
> to not be allowed.
>
>
> My current concern with the tri-state is people who set "=no". They
> will permanently degrade to C-L requests. That is problematic today,
> and especially as ra_serf advances. If the server admin upgrades to a
> chunked-enabled proxy, the client would still be in suckage-land.
>

Why would anyone change it to "no" in the first place?

In tristate, the default is "auto". The error message that mentions "no" only
appears for people who explicitly set "yes" (that is, changed the default)
*and* ran into a bad proxy. I think we can assume that people who set "yes"
know what they are doing --- they cared enough to change from "auto" to "yes",
so I believe they will be very much conscious of the cost of "no" and of the
fact they have that very-suboptimal-to-them option set.

> Further: consider if a client is thrown down in the C-L pit, then
> hey.. why NOT throw in some dynamic detection? Can't hurt them much
> more, so go ahead and detect.

Yes, that's exactly why the tristate defaults to "auto" and not to "yes" (like
the boolean option does) :-P
Received on 2013-07-12 04:51:46 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.