> On 14. Sep 2020, at 15:02, Robert Samuel Newson <rnew...@apache.org> wrote:
>
> Hi,
>
> There is no existing HTTP request header that I'm aware of that could cover
> this and inventing custom HTTP headers is not recommended (CouchDB has a fair
> few but I don't want to add to that pile).
>
> My preference is to remove the query parameter without replacement for this
> release, leaving it as just an administrator setting. We can enhance this in
> a future release.
Why should we remove this? I don’t think it is controversial.
Best
Jan
—
>
> B.
>
>> On 14 Sep 2020, at 13:51, Jan Lehnardt <j...@apache.org> wrote:
>>
>> On 14. Sep 2020, at 12:45, Richard Ellis <ricel...@uk.ibm.com> wrote:
>>>
>>> I've got concerns about the proposed API for the new buffer_response
>>> option. I have no issues with the intended behaviour or the chttp config
>>> option, but the choice of using a URL query parameter to control it when
>>> using the option "per request" seems unusual to me.
>>>
>>> As per HTTP spec https://tools.ietf.org/html/rfc7231#section-5
>>>
>>> "A client sends request header fields to ... **or modify the expected
>>> request processing**."
>>>
>>> As per URL spec https://tools.ietf.org/html/rfc3986#section-3.4
>>>
>>> "The query component contains non-hierarchical data that, along with data
>>> in the path component (Section 3.3), **serves to identify a resource**
>>> within the scope of the URI's scheme"
>>>
>>> Since this is a directive controlling the request processing on the server
>>> and is unrelated to identifying the resources it seems to me that the
>>> proposal is counter-intuitive to the specs and the option would be better
>>> placed in a header than a URL query parameter. It's not clear to me if
>>> there is some technical reason why a query parameter is preferable here or
>>> if this is perhaps following some (unknown to me) API convention or
>>> existing Couch API precedent (the closest thing I could think of was the r
>>> & w quorum options).
>>>
>>> Could anyone explain the API design choice to me or does anyone else have
>>> any concerns about this?
>>
>> I think your reading of the HTTP spec is apt and I wouldn’t object to an
>> addition of a header to control the behaviour.
>>
>> In the past API designs we opted for pragmatic choices when it came to
>> qs vs. headers and you could make similar arguments about the ?feed=
>> qs for _changes and there are likely others, too, where we opted to use
>> qs over (or in addition to) headers because we wanted to make a certain
>> feature easily accessible to environments where passing headers is non-
>> trivial, mostly, that’s a browser’s URL bar.
>>
>> I happily concede that the use-case for this is rather minor, but especially
>> in debugging cases, this keeps coming in handy.
>>
>>
>>> On 14. Sep 2020, at 12:58, Bessenyei Balázs Donát <bes...@apache.org> wrote:
>>>
>>> And I'm interested to see the discussion addressing Richard Ellis'
>>> concerns as any post-release changes to the "location" of the new
>>> control (qs -> header) would require a major version (in semver-land).
>>
>> I would say so, and in light of this, we wouldn’t like to a straight
>> transition
>> but deprecating the qs until the next more naturally occurring major version
>> and then removing it later, sometimes even next+1 if we don’t want to make
>> the upgrade path unnecessarily hard for end-users.
>>
>>
>> Best
>> Jan
>> —
>>
>>>
>>
>>
>>> Thanks,
>>> Rich
>>>
>>>
>>>
>>> From: Joan Touzet <woh...@apache.org>
>>> To: CouchDB Developers <dev@couchdb.apache.org>
>>> Date: 11/09/2020 23:53
>>> Subject: [EXTERNAL] [VOTE] Release Apache CouchDB 3.1.1 (RC2)
>>>
>>>
>>>
>>> Dear community,
>>>
>>> I would like to propose that we release Apache CouchDB 3.1.1.
>>>
>>> Changes since the last round:
>>>
>>>
>>> https://github.com/apache/couchdb/compare/3.1.1-RC1...3.1.1-RC2
>>>
>>>
>>> Candidate release notes:
>>>
>>>
>>> https://docs.couchdb.org/en/latest/whatsnew/3.1.html
>>>
>>>
>>> We encourage the whole community to download and test these release
>>> artefacts so that any critical issues can be resolved before the release
>>> is made. Everyone is free to vote on this release, so dig right in!
>>> (Only PMC members have binding votes, but they depend on community
>>> feedback to gauge if an official release is ready to be made.)
>>>
>>> The release artefacts we are voting on are available here:
>>>
>>>
>>> https://dist.apache.org/repos/dist/dev/couchdb/source/3.1.1/rc.2/
>>>
>>>
>>> There, you will find a tarball, a GPG signature, and SHA256/SHA512
>>> checksums.
>>>
>>> Please follow the test procedure here:
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
>>>
>>>
>>>
>>> Please remember that "RC2" is an annotation. If the vote passes, these
>>> artefacts will be released as Apache CouchDB 3.1.1.
>>>
>>> Because of the weekend, this vote will remain open until 5PM ET (UTC-4),
>>> Tuesday, 15 September 2020.
>>>
>>> Please cast your votes now.
>>>
>>> Thanks,
>>> Joan "once more unto the breech, dear friends" Touzet
>>>
>>>
>>>
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
