> -----Original Message-----
> From: Ben Reser [mailto:ben_at_reser.org]
> Sent: vrijdag 12 juli 2013 20:40
> To: Philip Martin; Greg Stein; Subversion Development
> Subject: Re: Tri-state for http-detect-chunking config option
>
> On Fri, Jul 12, 2013 at 10:48 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Fri, Jul 12, 2013 at 06:41:13PM +0100, Philip Martin wrote:
> >> Stefan Sperling <stsp_at_elego.de> writes:
> >>
> >> > So I think we should just accept the penalty of an extra request in
1.8.
> >> > And perhaps have a knob to turn auto-detection off if users really
care
> >> > about a bit of extra latency.
> >>
> >> That sounds like "http-chunked-requests=auto|yes|no" with auto being
> the
> >> default. Is there any difference?
> >
> > No. I don't think there is.
> >
> > But I've lost track what what the various option names and various
> > option settings mean to various people :)
>
> Two different option names are currently on the table.
>
> httpd-detect-chunking = no/yes (no is the current default). yes means
> perform an extra OPTIONS request. no means just use chunking without
> checking.
> httpd-chunked-requests = auto/yes/no (auto is the default). auto means
> perform an extra OPTIONs request, yes means just use chunking no
> detection, no means don't use chunking no detection.
>
> The options from Greg's first email are as followed described in the
> terms of those options:
>
> 1) http-detect-chunking as described above.
> 2) http-detect-chunking with yes as the default.
> 3) http-chunked-requests.
I prefer option 3.
I think it makes more sense to describe the option as the implementation,
then as the 'detect' phase.
Chunked requests:
Yes: force-enable chunked request
Auto: detect optimal behavior at a cost (default)
No: force-disable chunked requests
This option-name will still make sense after we find a more streamlined way
to detect the mode to use, while with a '-detect-' option set to yes, we
would still have to perform the check in future versions.
Bert
Received on 2013-07-12 21:43:29 CEST