Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
From: Nathan Vander Wilt <nate-lists@calftrail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B922C761-A2A0-4074-8CA3-024932A4D2D7"
Message-Id: <466BE6B6-8748-4F02-ABEA-414D1E24D0EA@calftrail.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Extra 500 reply added to list function response when accessed through rewrite
Date: Wed, 21 Jun 2017 10:07:36 -0700
References: <4F709517-AFCF-44A2-9290-FF7C4928FDD0@calftrail.com> <1830441581.2326.1498010152432.JavaMail.Joan@RITA>
To: user@couchdb.apache.org
In-Reply-To: <1830441581.2326.1498010152432.JavaMail.Joan@RITA>
archived-at: Wed, 21 Jun 2017 17:07:42 -0000

--Apple-Mail=_B922C761-A2A0-4074-8CA3-024932A4D2D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks, filed as https://github.com/apache/couchdb/issues/607.
-nvw

On Jun 20, 2017, at 6:55 PM, Joan Touzet <wohali@apache.org> wrote:

> Hi Nate,
>=20
> We've moved to GitHub Issues. A 500 with a stack trace is definitely =
evidence of a bug,
> we shouldn't ever return a 500 -- though I admit this is a bit of a =
corner case.
>=20
> https://github.com/apache/couchdb/issues
>=20
> I'm not able to dig in on your specific bug right now, but perhaps =
someone else can
> shed some light?
>=20
> Thanks,
> Joan
>=20
> ----- Original Message -----
> From: "Nathan Vander Wilt" <nate-lists@calftrail.com>
> To: user@couchdb.apache.org
> Sent: Tuesday, 20 June, 2017 7:04:05 PM
> Subject: Extra 500 reply added to list function response when accessed =
through rewrite
>=20
> I am getting strange responses from CouchDB 2.0.0 when accessing a =
list handler through a rewrite. The result to my single request is two =
responses: the expected one, plus an extra "unknown_error" 500 response. =
Over HTTP/1.1 this issue is masked because the extra response is not =
properly chunked, but over HTTP/1.0 the two responses appear as a single =
body before the connection is closed. So in local development the =
problem isn't seen in the browser, but when hosted behind an HTTP/1.0 =
proxy like nginx in production all clients will see the extra content =
appended to the intended HTML.
>=20
> Regardless of the HTTP version of the request, the behavior is =
accompanied in the console logs by:
>=20
>    [error] 2017-06-20T20:54:43.637726Z couchdb@localhost <0.23057.8> =
4d6c7d7e8f req_err(2053811356) unknown_error : undef
>        [<<"lacc:get/2">>,<<"chttpd:split_response/1 =
L343">>,<<"chttpd:handle_request_int/1 =
L234">>,<<"chttpd:process_request/1 =
L293">>,<<"chttpd:handle_request_int/1 =
L229">>,<<"mochiweb_http:headers/6 L122">>,<<"proc_lib:init_p_do_apply/3 =
L247">>]
>    [notice] 2017-06-20T20:54:43.637979Z couchdb@localhost <0.23057.8> =
4d6c7d7e8f undefined 127.0.0.1 undefined GET =
/test/_design/glob/_rewrite/2015/04/f1040_spreadsheet 500 ok 22
>=20
>=20
> Note there is no separate log for the initial "200" response, just the =
second "500" one.
>=20
> Turns out if I call `getRows()` an extra times in the list function =
(or if there are no matching rows), the extra 500 response does not =
happen. Also if I bypass the rewrite and query the list function =
directly, I do not see an extra response.
>=20
> So it seems there might be a bug, maybe something like "the rewrite =
handler generates an extra, broken response if a list function doesn't =
consume beyond all the available rows".
>=20
> Is this something I should file in JIRA, or have I made a mistake =
somewhere? Details below. (The original code can be seen at =
https://github.com/natevw/glob but I've simplified things down in my =
notes above and still seeing the issue.)
>=20
> thanks,
> -natevw
>=20
>=20
> ---
>=20
>=20
> The rewrite used looks like
>=20
>  "rewrites": [{
>      "from": "/:path1/:path2/:path3",
>      "to": "_list/posts/by_path",
>      "query": {
>          "include_docs": "true",
>          "key": [":path1",":path2",":path3"]
>      }
>  }]
>=20
> And the list function can be as simple as
>=20
>    function() {
>      return "[LIST FN OUTPUT]";
>    }
>=20
> When I query this such that "key" ends up matching a row from a simple =
"by_path" view, I get an extra garbage response when I access the =
rewrite:
>=20
>    $ telnet localhost 5984
>    GET /test/_design/glob/_rewrite/2015/04/f1040_spreadsheet
>=20
>    HTTP/1.1 200 OK
>    Connection: close
>    Content-Type: application/json
>    Date: Tue, 20 Jun 2017 20:34:49 GMT
>    Server: CouchDB/2.0.0 (Erlang OTP/19)
>=20
>    [LIST FN OUTPUT]HTTP/1.1 500 Internal Server Error
>    Cache-Control: must-revalidate
>    Connection: close
>    Content-Length: 60
>    Content-Type: application/json
>    Date: Tue, 20 Jun 2017 20:34:49 GMT
>    Server: CouchDB/2.0.0 (Erlang OTP/19)
>    X-Couch-Request-ID: 5e0e7f467b
>    X-Couch-Stack-Hash: 2053811356
>    X-CouchDB-Body-Time: 0
>=20
>    {"error":"unknown_error","reason":"undef","ref":2053811356}
>    Connection closed by foreign host.
>=20
>=20
> This does not happen with a direct request to the list, bypassing the =
rewrite:
>=20
>    GET =
/test/_design/glob/_list/posts/by_path?include_docs=3Dtrue&key=3D["2015","=
04","f1040_spreadsheet"]
>=20
>    HTTP/1.1 200 OK
>    Connection: close
>    Content-Type: application/json
>    Date: Tue, 20 Jun 2017 20:38:08 GMT
>    Server: CouchDB/2.0.0 (Erlang OTP/19)
>=20
>    [LIST FN OUTPUT]Connection closed by foreign host.
>=20
>=20
> Nor does it happen if I make a request through the rewrite targeting a =
"missing key", i.e. one that was not emitted by the view:
>=20
>    GET /test/_design/glob/_rewrite/2020/13/not_exist
>=20
>    HTTP/1.1 200 OK
>    Connection: close
>    Content-Type: application/json
>    Date: Tue, 20 Jun 2017 20:40:29 GMT
>    Server: CouchDB/2.0.0 (Erlang OTP/19)
>=20
>    [LIST FN OUTPUT]Connection closed by foreign host.
>=20
>=20
> If I change my list function to
>=20
>    function() {
>      getRow();
>      getRow();
>      return "[LIST FN OUTPUT]";
>    }
>=20
> then the problem goes away even when accessed via the rewrite. With =
just a single call to `getRow()` the extra response persists.
>=20
>=20
> Also note that the chunked responses of HTTP/1.1 mask this "double =
response" issue, so you'll see it in telnet or if CouchDB is behind =
nginx, but not in a browser or similar:=20
>=20
>=20
>    GET /test/_design/glob/_rewrite/2015/04/f1040_spreadsheet HTTP/1.1
>=20
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>    Date: Tue, 20 Jun 2017 20:50:12 GMT
>    Server: CouchDB/2.0.0 (Erlang OTP/19)
>    Transfer-Encoding: chunked
>=20
>    d
>    [LIST FN OUTPUT]
>    0
>=20
>    HTTP/1.1 500 Internal Server Error
>    Cache-Control: must-revalidate
>    Content-Length: 60
>    Content-Type: application/json
>    Date: Tue, 20 Jun 2017 20:50:12 GMT
>    Server: CouchDB/2.0.0 (Erlang OTP/19)
>    X-Couch-Request-ID: 524b67d8db
>    X-Couch-Stack-Hash: 2053811356
>    X-CouchDB-Body-Time: 0
>=20
>    {"error":"unknown_error","reason":"undef","ref":2053811356}
>=20


--Apple-Mail=_B922C761-A2A0-4074-8CA3-024932A4D2D7--