You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Scott Weber <sc...@sbcglobal.net> on 2014/04/14 05:14:28 UTC
Handle the Welcome Request
Greetings again,
I am trying to handle the Welcome message that appears from a root request.
I am using version 1.5 on a Windows machine.
Specifically I want to direct the "/" request to another url.
After hours of searching, the closest I found was this:
https://issues.apache.org/jira/browse/COUCHDB-472
which describes putting the changes in the [httpd_global_handlers] section.
So I followed the changes documented at18/Aug/09 14:43
I replaced the root handler with both suggestions in the log. Neither worked, they gave me a "500 server error".
For example I set this:
/ = {couch_httpd_misc_handlers, handle_welcome_req, {<<"Welcome">>,"/me/there/page.html"}}
In the couch log, I get:
httpd 500 error response:
{"error":"json_encode","reason":"{bad_term,{<<\"Welcome\">>,\"/me/there/page.html\"}}"}
Is there any other solution to this?
-Scott
Re: Handle the Welcome Request
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Apr 14, 2014 at 7:45 AM, Scott Weber <sc...@sbcglobal.net> wrote:
> I tried copying the handler from _utils:
>
> / = {couch_httpd_misc_handlers, handle_utils_dir_req, "/me/there/page.html"}
> I got:
>
> {"error":"unknown_error","reason":"function_clause"}
It expects to see path to directory (dir in handler name points on
that) instead of file there. Also make sure that this location is
readable for couchdb user.
--
,,,^..^,,,
Re: Handle the Welcome Request
Posted by Scott Weber <sc...@sbcglobal.net>.
Thanks, but that's not a lot to go on...
I tried copying the handler from _utils:
/ = {couch_httpd_misc_handlers, handle_utils_dir_req, "/me/there/page.html"}
I got:
{"error":"unknown_error","reason":"function_clause"}
I tried:
/ = {couch_httpd_misc_handlers, handle_welcome_req, "/me/there/page.html"}
and
/ = {couch_httpd_misc_handlers, handle_welcome_req, "../me/there/page.html"}
Same result.
By the way, the redirection is to a database/document/attachment, not a generic file on the disk (specifically a login for the app)
The log is 130 lines of error, not like the last time.
... GMT] [info] [<0.112.0>] Stacktrace: [{couch_httpd_db,handle_request,
[{httpd,
{mochiweb_request,
[#Port<0.4455>,'GET',"//",
{1,1},
{8,
{"host",
{'Host',"localhost:5984"},
{"accept",
{'Accept',
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},
nil,
{"accept-language",
{'Accept-Language',"en-US,en;q=0.5"},
{"accept-encoding",
{'Accept-Encoding',"gzip, deflate"},
nil,nil},
{"cookie",
{'Cookie',
"__utma=111872281.618741229.1391889742.1391889742.1391889742.1; __utmz=111872281.1391889742.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); TimeChoice=sweber"},
{"connection",
{'Connection',"keep-alive"},
{"cache-control",
{'Cache-Control',"max-age=0"},
nil,nil},
etc...
________________________________
From: Alexander Shorin <kx...@gmail.com>
To: "user@couchdb.apache.org" <us...@couchdb.apache.org>; Scott Weber <sc...@sbcglobal.net>
Sent: Sunday, April 13, 2014 10:23 PM
Subject: Re: Handle the Welcome Request
You probably would like to copy _utils global handler config value instead.
--
,,,^..^,,,
On Mon, Apr 14, 2014 at 7:14 AM, Scott Weber <sc...@sbcglobal.net> wrote:
> Greetings again,
> I am trying to handle the Welcome message that appears from a root request.
> I am using version 1.5 on a Windows machine.
>
>
> Specifically I want to direct the "/" request to another url.
> After hours of searching, the closest I found was this:
>
>
> https://issues.apache.org/jira/browse/COUCHDB-472
> which describes putting the changes in the [httpd_global_handlers] section.
>
> So I followed the changes documented at18/Aug/09 14:43
> I replaced the root handler with both suggestions in the log. Neither worked, they gave me a "500 server error".
> For example I set this:
>
>
> / = {couch_httpd_misc_handlers, handle_welcome_req, {<<"Welcome">>,"/me/there/page.html"}}
>
> In the couch log, I get:
> httpd 500 error response:
> {"error":"json_encode","reason":"{bad_term,{<<\"Welcome\">>,\"/me/there/page.html\"}}"}
>
>
> Is there any other solution to this?
>
> -Scott
Re: Handle the Welcome Request
Posted by Alexander Shorin <kx...@gmail.com>.
You probably would like to copy _utils global handler config value instead.
--
,,,^..^,,,
On Mon, Apr 14, 2014 at 7:14 AM, Scott Weber <sc...@sbcglobal.net> wrote:
> Greetings again,
> I am trying to handle the Welcome message that appears from a root request.
> I am using version 1.5 on a Windows machine.
>
>
> Specifically I want to direct the "/" request to another url.
> After hours of searching, the closest I found was this:
>
>
> https://issues.apache.org/jira/browse/COUCHDB-472
> which describes putting the changes in the [httpd_global_handlers] section.
>
> So I followed the changes documented at18/Aug/09 14:43
> I replaced the root handler with both suggestions in the log. Neither worked, they gave me a "500 server error".
> For example I set this:
>
>
> / = {couch_httpd_misc_handlers, handle_welcome_req, {<<"Welcome">>,"/me/there/page.html"}}
>
> In the couch log, I get:
> httpd 500 error response:
> {"error":"json_encode","reason":"{bad_term,{<<\"Welcome\">>,\"/me/there/page.html\"}}"}
>
>
> Is there any other solution to this?
>
> -Scott
Re: Handle the Welcome Request
Posted by Jens Alfke <je...@couchbase.com>.
On Apr 15, 2014, at 11:12 AM, Dale Harvey <da...@arandomurl.com> wrote:
> Saying its useless is wrong though, if you do a file based replication the
> databases should have the same uuid, it does in the pouch implementation at
> least, the entire point is that a host does not map to a database, its data
> does.
I remember being in a discussion of server UUIDs a few years ago. The issue I had is that in P2P replication (especially among mobile devices or laptops) a “server” may not have a stable URL. You may discover the same remote peer (using Bonjour or a DHT or whatever), but its IP address may not be the same as the last time.
In this case the CouchDB algorithm would start the replication over from the beginning because the remote URL doesn’t match. By using the remote UUID when available, you can avoid that.
Anyway, this is going off-topic for this thread. I was just misremembering about CouchDB doing a GET /.
IMHO, it’s still best to avoid rewriting / to some custom web page, because it is part of the API.
—Jens
Re: Handle the Welcome Request
Posted by Johannes Jörg Schmidt <sc...@netzmerk.com>.
This should work:
[vhosts]
test.localhost = /mydb/_design/myddoc/_rewrite
where myddoc is
{
"_id": "_design/myddoc",
"_rev": "1-743615f8003e4bd0d62adfb0c9406263",
"rewrites": [
{
"from": "/",
"to": "login.html"
}
],
"_attachments": {
"login.html": {
"data": "asdf=",
"content_type": "text/html",
...
}
}
}
Greetings
Johannes
On 15.04.2014 23:08, Scott Weber wrote:
> Now that is discussion is back on the original track... :-)
>
> I still can't get it to work. Vhost + rewrite isn't doing it.
>
> First:
> My document "source" has an attachment called "login.html"
>
> So:
> [vhosts]
> test.localhost = /login/source/
> is working. (yes, I made that a local definition for testing)
> It is giving me the document called 'source'.
>
> Next:
> Rewrite is not. Trying all sorts of combos of what this page says:
> https://wiki.apache.org/couchdb/Rewriting_urls
>
> My doc is this:
>
> {
> "_id": "_design/_rewrite",
> "_rev": "6-743615f8003e4bd0d62adfb0c9406263",
> "rewrites": [
> {
> "from": "/",
> "to": "login.html"
> }
> ]
> }
>
> But all I ever get is the DBDoc.
>
> I have made 6+ revisions already. I did not paste them all.
> I have made a bunch of variations on the name: "_design/_rewrite" "_design/rewrite" "_design/source"...
>
> All the log says is: ... [<0.440.0>] 127.0.0.1 - - GET /login/source/ 200
>
> Rather than continue to shoot in the dark... it's time to ask for help again.
>
>
>
>
> ________________________________
> From: Robert Samuel Newson <rn...@apache.org>
> To: user@couchdb.apache.org
> Cc: Scott Weber <sc...@sbcglobal.net>
> Sent: Tuesday, April 15, 2014 2:10 PM
> Subject: Re: Handle the Welcome Request
>
>
>
> Regardless of whether changing GET / would break current replication it’s still not a smart move. It breaks compatibility by definition. It’s also unnecessary, a vhost + rewrite setup can obviously serve a suitable page for / for the vhost.
>
> And if couchdb isn’t using the source and target uuid’s, where available, it should in a future release.
>
> B.
>
>
>
> On 15 Apr 2014, at 19:12, Dale Harvey <da...@arandomurl.com> wrote:
>
>> Yup as far as the implementation thats right,
>> https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_utils.erl#L62
>>
>> Saying its useless is wrong though, if you do a file based replication the
>> databases should have the same uuid, it does in the pouch implementation at
>> least, the entire point is that a host does not map to a database, its data
>> does.
>>
>> Pouch uses a get on / to fetch the uuid, it will use the host if that
>> request fails, that just means < 1.3 couchdb's and ones that plays around
>> with / will fallback and more likely to do redundant replications in the
>> case of a changed host.
>>
>> Theres a related post on the replication mailing list
>> http://mail-archives.apache.org/mod_mbox/couchdb-replication/201404.mbox/browserin
>> which I think having per db uuid's would be beneficial for multiple
>> reasons
>>
>>
>> On 15 April 2014 18:50, Alexander Shorin <kx...@gmail.com> wrote:
>>
>>> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <je...@couchbase.com> wrote:
>>>> On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>>>
>>>>> Not, it wouldn't. The replicator doesn't request source or target UUID
>>>>> via API, but takes the value from server which runs the replication.
>>>>
>>>> No, I meant the _remote_ server’s UUID. The only way to get that is to
>>> send a "GET /" request.
>>>>
>>>> Anyway, I’m trying to verify this but not seeing it right now. I’m
>>> seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem
>>> redundant!] but not the GET /. Pretty sure I’ve seen this in the past,
>>> though, and it does seem the only way for the replicator to get the UUID,
>>> which is used to construct the checkpoint ID (right?)
>>>
>>> No, there wasn't ever used GET / request in CouchDB replication.
>>> Server UUID was introduced in 1.3 release: before it pair (host,port)
>>> was used and since that time no changes were made for that process.
>>> The remote server UUID usage is a little useless, since replication ID
>>> for protocol version 3 between two remote servers is based on next
>>> structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
>>> Headers}}. If you replace LocalUUID with any remote server's UUID
>>> value this would change nothing, but will cost you one additional
>>> request, losing portability since pre-1.3 releases has no UUID value
>>> and replication startover in case when remote database will be
>>> migrated to the another instance with the same URL (some
>>> proxy/balancer in front of remote instance is the common case).
>>>
>>> --
>>> ,,,^..^,,,
>>>
Re: Handle the Welcome Request
Posted by Scott Weber <sc...@sbcglobal.net>.
Now that is discussion is back on the original track... :-)
I still can't get it to work. Vhost + rewrite isn't doing it.
First:
My document "source" has an attachment called "login.html"
So:
[vhosts]
test.localhost = /login/source/
is working. (yes, I made that a local definition for testing)
It is giving me the document called 'source'.
Next:
Rewrite is not. Trying all sorts of combos of what this page says:
https://wiki.apache.org/couchdb/Rewriting_urls
My doc is this:
{
"_id": "_design/_rewrite",
"_rev": "6-743615f8003e4bd0d62adfb0c9406263",
"rewrites": [
{
"from": "/",
"to": "login.html"
}
]
}
But all I ever get is the DBDoc.
I have made 6+ revisions already. I did not paste them all.
I have made a bunch of variations on the name: "_design/_rewrite" "_design/rewrite" "_design/source"...
All the log says is: ... [<0.440.0>] 127.0.0.1 - - GET /login/source/ 200
Rather than continue to shoot in the dark... it's time to ask for help again.
________________________________
From: Robert Samuel Newson <rn...@apache.org>
To: user@couchdb.apache.org
Cc: Scott Weber <sc...@sbcglobal.net>
Sent: Tuesday, April 15, 2014 2:10 PM
Subject: Re: Handle the Welcome Request
Regardless of whether changing GET / would break current replication it’s still not a smart move. It breaks compatibility by definition. It’s also unnecessary, a vhost + rewrite setup can obviously serve a suitable page for / for the vhost.
And if couchdb isn’t using the source and target uuid’s, where available, it should in a future release.
B.
On 15 Apr 2014, at 19:12, Dale Harvey <da...@arandomurl.com> wrote:
> Yup as far as the implementation thats right,
> https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_utils.erl#L62
>
> Saying its useless is wrong though, if you do a file based replication the
> databases should have the same uuid, it does in the pouch implementation at
> least, the entire point is that a host does not map to a database, its data
> does.
>
> Pouch uses a get on / to fetch the uuid, it will use the host if that
> request fails, that just means < 1.3 couchdb's and ones that plays around
> with / will fallback and more likely to do redundant replications in the
> case of a changed host.
>
> Theres a related post on the replication mailing list
> http://mail-archives.apache.org/mod_mbox/couchdb-replication/201404.mbox/browserin
> which I think having per db uuid's would be beneficial for multiple
> reasons
>
>
> On 15 April 2014 18:50, Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <je...@couchbase.com> wrote:
>>> On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>>
>>>> Not, it wouldn't. The replicator doesn't request source or target UUID
>>>> via API, but takes the value from server which runs the replication.
>>>
>>> No, I meant the _remote_ server’s UUID. The only way to get that is to
>> send a "GET /" request.
>>>
>>> Anyway, I’m trying to verify this but not seeing it right now. I’m
>> seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem
>> redundant!] but not the GET /. Pretty sure I’ve seen this in the past,
>> though, and it does seem the only way for the replicator to get the UUID,
>> which is used to construct the checkpoint ID (right?)
>>
>> No, there wasn't ever used GET / request in CouchDB replication.
>> Server UUID was introduced in 1.3 release: before it pair (host,port)
>> was used and since that time no changes were made for that process.
>> The remote server UUID usage is a little useless, since replication ID
>> for protocol version 3 between two remote servers is based on next
>> structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
>> Headers}}. If you replace LocalUUID with any remote server's UUID
>> value this would change nothing, but will cost you one additional
>> request, losing portability since pre-1.3 releases has no UUID value
>> and replication startover in case when remote database will be
>> migrated to the another instance with the same URL (some
>> proxy/balancer in front of remote instance is the common case).
>>
>> --
>> ,,,^..^,,,
>>
Re: Handle the Welcome Request
Posted by Robert Samuel Newson <rn...@apache.org>.
Regardless of whether changing GET / would break current replication it’s still not a smart move. It breaks compatibility by definition. It’s also unnecessary, a vhost + rewrite setup can obviously serve a suitable page for / for the vhost.
And if couchdb isn’t using the source and target uuid’s, where available, it should in a future release.
B.
On 15 Apr 2014, at 19:12, Dale Harvey <da...@arandomurl.com> wrote:
> Yup as far as the implementation thats right,
> https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_utils.erl#L62
>
> Saying its useless is wrong though, if you do a file based replication the
> databases should have the same uuid, it does in the pouch implementation at
> least, the entire point is that a host does not map to a database, its data
> does.
>
> Pouch uses a get on / to fetch the uuid, it will use the host if that
> request fails, that just means < 1.3 couchdb's and ones that plays around
> with / will fallback and more likely to do redundant replications in the
> case of a changed host.
>
> Theres a related post on the replication mailing list
> http://mail-archives.apache.org/mod_mbox/couchdb-replication/201404.mbox/browserin
> which I think having per db uuid's would be beneficial for multiple
> reasons
>
>
> On 15 April 2014 18:50, Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <je...@couchbase.com> wrote:
>>> On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>>
>>>> Not, it wouldn't. The replicator doesn't request source or target UUID
>>>> via API, but takes the value from server which runs the replication.
>>>
>>> No, I meant the _remote_ server’s UUID. The only way to get that is to
>> send a "GET /" request.
>>>
>>> Anyway, I’m trying to verify this but not seeing it right now. I’m
>> seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem
>> redundant!] but not the GET /. Pretty sure I’ve seen this in the past,
>> though, and it does seem the only way for the replicator to get the UUID,
>> which is used to construct the checkpoint ID (right?)
>>
>> No, there wasn't ever used GET / request in CouchDB replication.
>> Server UUID was introduced in 1.3 release: before it pair (host,port)
>> was used and since that time no changes were made for that process.
>> The remote server UUID usage is a little useless, since replication ID
>> for protocol version 3 between two remote servers is based on next
>> structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
>> Headers}}. If you replace LocalUUID with any remote server's UUID
>> value this would change nothing, but will cost you one additional
>> request, losing portability since pre-1.3 releases has no UUID value
>> and replication startover in case when remote database will be
>> migrated to the another instance with the same URL (some
>> proxy/balancer in front of remote instance is the common case).
>>
>> --
>> ,,,^..^,,,
>>
Re: Handle the Welcome Request
Posted by Dale Harvey <da...@arandomurl.com>.
Yup as far as the implementation thats right,
https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_utils.erl#L62
Saying its useless is wrong though, if you do a file based replication the
databases should have the same uuid, it does in the pouch implementation at
least, the entire point is that a host does not map to a database, its data
does.
Pouch uses a get on / to fetch the uuid, it will use the host if that
request fails, that just means < 1.3 couchdb's and ones that plays around
with / will fallback and more likely to do redundant replications in the
case of a changed host.
Theres a related post on the replication mailing list
http://mail-archives.apache.org/mod_mbox/couchdb-replication/201404.mbox/browserin
which I think having per db uuid's would be beneficial for multiple
reasons
On 15 April 2014 18:50, Alexander Shorin <kx...@gmail.com> wrote:
> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <je...@couchbase.com> wrote:
> > On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kx...@gmail.com> wrote:
> >
> >> Not, it wouldn't. The replicator doesn't request source or target UUID
> >> via API, but takes the value from server which runs the replication.
> >
> > No, I meant the _remote_ server’s UUID. The only way to get that is to
> send a "GET /" request.
> >
> > Anyway, I’m trying to verify this but not seeing it right now. I’m
> seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem
> redundant!] but not the GET /. Pretty sure I’ve seen this in the past,
> though, and it does seem the only way for the replicator to get the UUID,
> which is used to construct the checkpoint ID (right?)
>
> No, there wasn't ever used GET / request in CouchDB replication.
> Server UUID was introduced in 1.3 release: before it pair (host,port)
> was used and since that time no changes were made for that process.
> The remote server UUID usage is a little useless, since replication ID
> for protocol version 3 between two remote servers is based on next
> structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
> Headers}}. If you replace LocalUUID with any remote server's UUID
> value this would change nothing, but will cost you one additional
> request, losing portability since pre-1.3 releases has no UUID value
> and replication startover in case when remote database will be
> migrated to the another instance with the same URL (some
> proxy/balancer in front of remote instance is the common case).
>
> --
> ,,,^..^,,,
>
Re: Handle the Welcome Request
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <je...@couchbase.com> wrote:
> On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kx...@gmail.com> wrote:
>
>> Not, it wouldn't. The replicator doesn't request source or target UUID
>> via API, but takes the value from server which runs the replication.
>
> No, I meant the _remote_ server’s UUID. The only way to get that is to send a "GET /" request.
>
> Anyway, I’m trying to verify this but not seeing it right now. I’m seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem redundant!] but not the GET /. Pretty sure I’ve seen this in the past, though, and it does seem the only way for the replicator to get the UUID, which is used to construct the checkpoint ID (right?)
No, there wasn't ever used GET / request in CouchDB replication.
Server UUID was introduced in 1.3 release: before it pair (host,port)
was used and since that time no changes were made for that process.
The remote server UUID usage is a little useless, since replication ID
for protocol version 3 between two remote servers is based on next
structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
Headers}}. If you replace LocalUUID with any remote server's UUID
value this would change nothing, but will cost you one additional
request, losing portability since pre-1.3 releases has no UUID value
and replication startover in case when remote database will be
migrated to the another instance with the same URL (some
proxy/balancer in front of remote instance is the common case).
--
,,,^..^,,,
Re: Handle the Welcome Request
Posted by Jens Alfke <je...@couchbase.com>.
On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kx...@gmail.com> wrote:
> Not, it wouldn't. The replicator doesn't request source or target UUID
> via API, but takes the value from server which runs the replication.
No, I meant the _remote_ server’s UUID. The only way to get that is to send a "GET /" request.
Anyway, I’m trying to verify this but not seeing it right now. I’m seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem redundant!] but not the GET /. Pretty sure I’ve seen this in the past, though, and it does seem the only way for the replicator to get the UUID, which is used to construct the checkpoint ID (right?)
—Jens
Re: Handle the Welcome Request
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Apr 15, 2014 at 2:59 AM, Jens Alfke <je...@couchbase.com> wrote:
> On Apr 13, 2014, at 8:14 PM, Scott Weber <sc...@sbcglobal.net> wrote:
>
>> Specifically I want to direct the "/" request to another url.
>
> I think doing that might break replication, because “/“ is part of the API. The pull replicator issues a “GET /” request when it starts, to look up the remote server's UUID and version. If it got an unexpected response, like a bunch of HTML, it might just fail with an error.
Not, it wouldn't. The replicator doesn't request source or target UUID
via API, but takes the value from server which runs the replication.
At least that's how CouchDB's replicator works. As for others, no such
warranty could be given.
--
,,,^..^,,,
Re: Handle the Welcome Request
Posted by Jens Alfke <je...@couchbase.com>.
On Apr 13, 2014, at 8:14 PM, Scott Weber <sc...@sbcglobal.net> wrote:
> Specifically I want to direct the "/" request to another url.
I think doing that might break replication, because “/“ is part of the API. The pull replicator issues a “GET /” request when it starts, to look up the remote server's UUID and version. If it got an unexpected response, like a bunch of HTML, it might just fail with an error.
—Jens