incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Jörg Schmidt <schm...@netzmerk.com>
Subject Re: Handle the Welcome Request
Date Tue, 15 Apr 2014 21:22:51 GMT
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 <rnewson@apache.org>
> To: user@couchdb.apache.org 
> Cc: Scott Weber <scotty2541@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 <dale@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 <kxepal@gmail.com> wrote:
>>
>>> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <jens@couchbase.com> wrote:
>>>> On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kxepal@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).
>>>
>>> --
>>> ,,,^..^,,,
>>>



Mime
View raw message