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. 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
