Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
'$' mean? Maybe it is like shell variables? For you sysadmin that know only shell and figure that $ is only use in shell ;) this issue is now gone in last commit. : are now used like in the _rewrite handler. For the issue of jchris, I think we should answer to potential problems in the ticket. - benoit
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 11:12 PM, Jason Smith j...@couch.io wrote: On Fri, Aug 20, 2010 at 04:02, Paul Davis paul.joseph.da...@gmail.comwrote: Still confused. A couchapp developer shouldn't require any sort of configuration because that's not under their control. For a couchapp to be couchappy, its going to be barred from *requiring* such configuration or it'll never work on the wide number of clients that would be expected to host them as Chris points out. Indeed. However I think in practice, couch app developers demand that the URL looks reasonable. Benoit mentioned that vhost and _rewrite are already becoming very popular with developers. Welll both aren't incompatible. You can totally do today a CouchApp that will adapt its routing depending if it's behind a vhost or not. 2 possibilities today: 1) Use the rewriter and fix a db path : /db - ../.. /db/* - ../../* and then use this path as default db path in your app. It will always work if you run your app behind _rewrite. 2) Detect if path have been rewritten using req.requested_path and comparing to req.path in shows, lists, updates function. Now I reckon /db/_design/ddoc/_rewrite/ is a little ugly and that would be good to shorten this path. Maybe by using the ini like suggest jchris I think . Which would be the easiest actually, though I'm not fan of auto declaration which may cause a security issue (admin that forgot to logout , user replicating a non trusted couchapp, ..). Also there will be a limit to the number of apps possible. I've updated the ticket about these questions. - benoit
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900814#action_12900814 ] Chris Anderson commented on COUCHDB-230: I'm am starting to get concerned about this feature (and the $foo pattern matching vhosts stuff as well) mostly because I'm not sure I understand all the implications of it. In the past when features have been proposed that have been complex enough to not be easy to reason about, we've decided against them. I'm not saying that's what we need to do hear, but I think that until we are totally clear about what we are and aren't getting into with this stuff, we should proceed with caution. Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 Attachments: 0001-manage-aliases.patch It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900825#action_12900825 ] Benoit Chesneau commented on COUCHDB-230: - Ok, I'm starting to be annoyed now. Can you for just explain what is the issue? Current implementation doesn't change anything to what is was in the past. Time to ask for the community I guess. Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 Attachments: 0001-manage-aliases.patch It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 01:48, Benoit Chesneau (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899954#action_12899954] Benoit Chesneau commented on COUCHDB-230: - the $ stuff is already in the code with the vhost refactoring. The only thing to add is this path stuff which is a little more complex btw. I will work on it this week, it will likely land on friday. Woah! Can we all please take a step back and talk about what problem this solves? Benoit, your work is *excellent* however on behalf of couchdb administrators, I must say, these proposed vhost rules look complicated, and difficult or impossible to support in a reverse-proxy environment. What exactly is the problem that vhosts and _rewrite cannot solve? I have no final opinion. However I think a CouchApp or Futon feature which manages vhosts might be better, long-term, despite being more work to implement at this time. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 2:30 PM, Jason Smith j...@couch.io wrote: Woah! Can we all please take a step back and talk about what problem this solves? Not everyone want to use a proxy to do smart vhosting. Not everyone do mass hosting. Some people just want to host their couchdb on port 80 like some tshirt said. Benoit, your work is *excellent* however on behalf of couchdb administrators, I must say, these proposed vhost rules look complicated, and difficult or impossible to support in a reverse-proxy environment. I don't see how it changed compared to previous system. before : check Host, use rewrite rule now: check Host or X-Forwarded-Host , use rewrite rule what was added, is a way to make the rewrite rule smarter. So no change for people using a reverse proxy. More over now work is easier for proxy since they can use the X-Forwarded-Host header which wasn't possible before. What exactly is the problem that vhosts and _rewrite cannot solve? I have 1000 apps on 1000 dbs, each of this app want to have a nice domain name. Rather than having 1000 lines i can just do now : $appname.$dbname.mydomain.tld = /$dbname/_design/$appname/_rewrite other : rather than having 2 lines for www. and . I can just do : *.domain.tlld = /db/ Pb to solve, deploying just a couchdb rather than a couchdb + a proxy ++ . I have no final opinion. However I think a CouchApp or Futon feature which manages vhosts might be better, long-term, despite being more work to implement at this time. I don't see how it could work If vhost isn't implemented on server side it can't work. - benoit
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 21:19, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 2:30 PM, Jason Smith j...@couch.io wrote: Woah! Can we all please take a step back and talk about what problem this solves? Not everyone want to use a proxy to do smart vhosting. Not everyone do mass hosting. Some people just want to host their couchdb on port 80 like some tshirt said. Yes, however these changes make it impossible to move a couch behind a proxy. That would be unfortunate. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 4:22 PM, Jason Smith j...@couch.io wrote: On Thu, Aug 19, 2010 at 21:19, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 2:30 PM, Jason Smith j...@couch.io wrote: Woah! Can we all please take a step back and talk about what problem this solves? Not everyone want to use a proxy to do smart vhosting. Not everyone do mass hosting. Some people just want to host their couchdb on port 80 like some tshirt said. Yes, however these changes make it impossible to move a couch behind a proxy. That would be unfortunate. Could you explain me how it's impossible compared to previous behaviour ? It doesn't change anything technically. Please post all your concern and a way to reproduce , I will have a look on it. Though here hosting 50 couch - trunk behingd couchdbproxy works. tested yesterday. If you have specifi concern like forbid a vhost (furon.couchone.com for ex-) you could use your own redirect vhost function it's just 4-6 lines of code. - benoit - benoit.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 4:27 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 4:22 PM, Jason Smith j...@couch.io wrote: On Thu, Aug 19, 2010 at 21:19, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 2:30 PM, Jason Smith j...@couch.io wrote: Woah! Can we all please take a step back and talk about what problem this solves? Not everyone want to use a proxy to do smart vhosting. Not everyone do mass hosting. Some people just want to host their couchdb on port 80 like some tshirt said. Yes, however these changes make it impossible to move a couch behind a proxy. That would be unfortunate. Could you explain me how it's impossible compared to previous behaviour ? It doesn't change anything technically. Please post all your concern and a way to reproduce , I will have a look on it. Though here hosting 50 couch - trunk behingd couchdbproxy works. tested yesterday. If you have specifi concern like forbid a vhost (furon.couchone.com for ex-) you could use your own redirect vhost function it's just 4-6 lines of code. - benoit - benoit. s/furon/futon ...
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau bchesn...@gmail.com wrote: Could you explain me how it's impossible compared to previous behaviour ? It doesn't change anything technically. Please post all your concern and a way to reproduce , I will have a look on it. Though here hosting 50 couch - trunk behingd couchdbproxy works. tested yesterday. ## The top priority question: How can proxies managed by the sysadmin or network admin know what to do? Now, vhost is explicit. Anybody with permission can query /_config/vhosts for all couches. With wildcards, e.g. */blog, it is impossible to know all domains which the web server handles. When a query for fooapp.foodb.mydomain.tld arrives, which couch should handle it? CouchDB adoption is growing. The network, system, and programming responsibilities are becoming different people. It needs to allow everybody to do their job. ## The medium priority question I have not decided how I feel about smart vhosts. Is it really wrong with 1,000 vhost entries? For sure, *something* must be smart to allow managing 1,000 couchapps, however I am not sure if the vhost is the best answer. One possibility is CouchApp. Currently, CouchApp has no idea about rewrites and vhosts, `rewrites.json` is plain old data. Maybe CouchApp is the best place to set vhosts and rewrites. The .couchapprc is 3 nested JSON objects! Is a good place to say, when you push to this URL, please also configure vhosts so fooapp.foodb.mydomain.tld will go to _rewrite? Another possibility is a dedicated tool to manage CouchDB, perhaps within Futon, or perhaps standalone. Besides vhosts, there are many things that are becoming difficult to manage. * Database _security object * _config * _users (mostly changing passwords but also role management is quite basic) When deploying a CouchApp, these must be synchronized between development and production (_users could replicate). In other words, vhost is not the only problem when you have 1,000 CouchApps. I think all these problems are related: there is no app management console yet. ## The low priority question: Finally, as a sysadmin, wonder about the $var - $var syntax. I do not enjoy learning another domain-specific language just to get my job done. What does '$' mean? Maybe it is like shell variables? But shell variables do not use '$ when assigning, only when expanding. What other differences are there? What about underscore? Does $foo_bar match anything, or only anything+_bar? Ultimately, I must look in the documentation to make sure. There is already a syntax for this included in Erlang: regular expressions. (.*).(.*).mydomain.tld - /$2/_design/$1/_rewrite Finally, I am happy to get new changes, just trying to figure out what is best for everybody. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
To answer in a more generic way. As a sys admin or operatives, you
are already habit to vhosts or Locations with http servers. This is
the same system here. Nothing new, just a syntax different.
I think also there is 2 views of couchdb in oposition here. One is
about managing couchdb in multi mass hosting other is to see couchdb
as a standalone db that could be used on any device.
Now answering to other questions:
On Thu, Aug 19, 2010 at 4:59 PM, Jason Smith j...@couch.io wrote:
On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau bchesn...@gmail.com wrote:
Could you explain me how it's impossible compared to previous
behaviour ? It doesn't change anything technically. Please post all
your concern and a way to reproduce , I will have a look on it. Though
here hosting 50 couch - trunk behingd couchdbproxy works. tested
yesterday.
## The top priority question:
How can proxies managed by the sysadmin or network admin know what to do?
Now, vhost is explicit. Anybody with permission can query /_config/vhosts
for all couches.
That was the case since Jan added this features. Nothing changed and I
think that couchone is running.
With wildcards, e.g. */blog, it is impossible to know all domains which
the web server handles. When a query for fooapp.foodb.mydomain.tld arrives,
which couch should handle it?
This feature isn't yet implemented. It only works for domain names.
You don't need to use a wildcard. If you're worried about your users
and the fact they could use this feature, I am thinking this is just
an operative concern. If you don't want that your user set vhosts like
this then you will have to think to a way to do this. I'm not sure
that couchdb should concern about it, especially since you can
whitelist _config. You could also create your own _config handler that
filter entries .
Other simple way. Use your own vhost rewriter :
in ini :
[httpd]
redirect_vhost_handler = {couchone_httpd, vhost_handler}
then
vhost_handler(MochiReq, VhostTarget) -
Path = MochiReq:get(raw_path),
{/ ++ TargetPath, _, _} = mochiweb_util:urlsplit_path(VhostTarget),
{Firstpart, _, _} = mochiweb_util:partition(TargetPath, /),
%% get target path
Target = case DbName of
'_utils -
...
_ -
AppPath = VhostTarget ++ Path
end,
?LOG_DEBUG(Vhost Target: '~p'~n, [Target]),
Headers = mochiweb_headers:enter(x-couchdb-vhost-path, Path,
MochiReq:get(headers)),
% build a new mochiweb request
MochiReq1 = mochiweb_request:new(MochiReq:get(socket),
MochiReq:get(method),
Target,
MochiReq:get(version),
Headers),
% cleanup, It force mochiweb to reparse raw uri.
MochiReq1:cleanup(),
MochiReq1.
done.
CouchDB adoption is growing. The network, system, and programming
responsibilities are becoming different people. It needs to allow everybody
to do their job.
## The medium priority question
I have not decided how I feel about smart vhosts.
Is it really wrong with 1,000 vhost entries? For sure, *something* must be
smart to allow managing 1,000 couchapps, however I am not sure if the vhost
is the best answer.
One possibility is CouchApp. Currently, CouchApp has no idea about rewrites
and vhosts, `rewrites.json` is plain old data. Maybe CouchApp is the best
place to set vhosts and rewrites. The .couchapprc is 3 nested JSON objects!
Is a good place to say, when you push to this URL, please also configure
vhosts so fooapp.foodb.mydomain.tld will go to _rewrite?
I don't think it could work. You don't want to read all dbs to know if
an host was set.
Another possibility is a dedicated tool to manage CouchDB, perhaps within
Futon, or perhaps standalone. Besides vhosts, there are many things that are
becoming difficult to manage.
* Database _security object
* _config
* _users (mostly changing passwords but also role management is quite
basic)
When deploying a CouchApp, these must be synchronized between development
and production (_users could replicate). In other words, vhost is not the
only problem when you have 1,000 CouchApps. I think all these problems are
related: there is no app management console yet.
I know at least one but not public yet.
## The low priority question:
Finally, as a sysadmin, wonder about the $var - $var syntax. I do not enjoy
learning another domain-specific language just to get my job done. What does
'$' mean? Maybe it is like shell variables? But shell variables do not use
'$ when assigning, only when expanding. What other differences are there?
What about underscore? Does $foo_bar match anything, or only
anything+_bar? Ultimately, I must look in the documentation to make sure.
There is already a syntax for this included in Erlang: regular expressions.
(.*).(.*).mydomain.tld - /$2/_design/$1/_rewrite
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On 19 Aug 2010, at 16:23, Benoit Chesneau wrote: Regexps are complicated, Regexps are slow (especially in erlang). This is generally false. I'd want to seem some data to back it up as a justification. If you're going to allow this kind of pattern matching, I would use regexps until it was proven inefficient.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On 19 Aug 2010, at 16:49, Benoit Chesneau wrote: Well asking without giving yourself some data make it irrelevant but Not really. I'm suggesting that if we're going to use performance as an argument, we use data and not supposition. Pattern matching is more efficient in erlang. Why would would you use regexp where it's not needed. regexp give an extra level of complexity we don't need here. Should we be I in that sentence? :)
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 5:56 PM, Noah Slater nsla...@apache.org wrote: On 19 Aug 2010, at 16:49, Benoit Chesneau wrote: Well asking without giving yourself some data make it irrelevant but Not really. I'm suggesting that if we're going to use performance as an argument, we use data and not supposition. The way pattern matching works should explain by itself though ;) Pattern matching is more efficient in erlang. Why would would you use regexp where it's not needed. regexp give an extra level of complexity we don't need here. Should we be I in that sentence? :) *I* was speaking for the project, maybe I'm too much implicated :/ Now I won't try to prove anything, I'm too much busy these day unfortunately. I just used what I thought was the right tool. Same system is used in _rewrite handler so why using another way to do it. Btw, regexp was tried for _rewrite too and it would have slow the process + make it more difficult to use . Now I can remove this pattern matching from the code, but the problem Jason raised will stay. Current system in trunk doesn't change anything to the way vhosts are actually handled in 1.0.1, so the problem Jason have is already in 1.0.1. What I see on the other hand is that couchone.com is running. Also, I introduced the X-Forwarded-Host especially for reverse-proxy and it should solve that.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 23:14, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 5:56 PM, Noah Slater nsla...@apache.org wrote: On 19 Aug 2010, at 16:49, Benoit Chesneau wrote: Well asking without giving yourself some data make it irrelevant but Not really. I'm suggesting that if we're going to use performance as an argument, we use data and not supposition. The way pattern matching works should explain by itself though ;) AFAIK Erlang ships with Perl-compatible regular expressions written in C. re:compile() Anyway the whole performance argument is not relevant. Who cares? You are about to do a b-tree lookup from the hard disk. How much will regex vs. pattern match on a 20-byte string matter? My point was, why are we inventing syntax out of our asses for every different situation? Regular expressions should be considered because: 1. They match patterns 2. They capture groups and can access them later 3. Everybody knows them -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 6:30 PM, Jason Smith j...@couch.io wrote: On Thu, Aug 19, 2010 at 23:14, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 5:56 PM, Noah Slater nsla...@apache.org wrote: On 19 Aug 2010, at 16:49, Benoit Chesneau wrote: Well asking without giving yourself some data make it irrelevant but Not really. I'm suggesting that if we're going to use performance as an argument, we use data and not supposition. The way pattern matching works should explain by itself though ;) AFAIK Erlang ships with Perl-compatible regular expressions written in C. re:compile() Yes. so ? Anyway the whole performance argument is not relevant. Who cares? You are about to do a b-tree lookup from the hard disk. How much will regex vs. pattern match on a 20-byte string matter? b-tree ? Where ? My point was, why are we inventing syntax out of our asses for every different situation? Regular expressions should be considered because: 1. They match patterns yes. Pattern matching too but we only match terms, and they are common in Erlang. 2. They capture groups and can access them later yes. who care ? A lot of urls rewriters are not using regexp because it adds an extra layer of complexity: webmachine in erlang, werzeug in python, ... 3. Everybody knows them that's not true. http://xkcd.com/208/ To answer to this reinventing . We had long discussions on how to manage rewriting in couchapps. Some included regexp, we fall in the current system. Ie pattern matching because it was a lot easier to understand and *simple*. SInce the system is already in place, I wanted to reuse it too, there is no need to have 2 dofferent ways to handle rewriting. I would like to keep it *simple*, that's the key. Anyway, can we go back to the topic ? I still don't understand how vhosts in 1.0.1 or in trunk are a problem ? About that I'm thinking we could propse a request_handler that isn't relying to vhost at all and make them an option, would it be ok ?
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On 19 Aug 2010, at 17:48, Benoit Chesneau wrote: 3. Everybody knows them that's not true. http://xkcd.com/208/ To answer to this reinventing . We had long discussions on how to manage rewriting in couchapps. Some included regexp, we fall in the current system. Ie pattern matching because it was a lot easier to understand and *simple*. SInce the system is already in place, I wanted to reuse it too, there is no need to have 2 dofferent ways to handle rewriting. I would like to keep it *simple*, that's the key. We're approaching bike shed territory... :D
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 22:23, Benoit Chesneau bchesn...@gmail.com wrote: To answer in a more generic way. As a sys admin or operatives, you are already habit to vhosts or Locations with http servers. This is the same system here. Nothing new, just a syntax different. I think also there is 2 views of couchdb in oposition here. One is about managing couchdb in multi mass hosting other is to see couchdb as a standalone db that could be used on any device. Back around 0.9, there was a huge discussion about transactional bulk inserts. The prevailing view was that CouchDB does not show a behavior unless it can show that behavior in all possible deployments. I am asking if the same logic applies here. In the future when every device has CouchDB and every ISP runs it and every carrier caches it and everything, apps need to work there too. That is why I am attracted to a simple vhost implementation. This feature isn't yet implemented. It only works for domain names. You don't need to use a wildcard. If you're worried about your users and the fact they could use this feature, I am thinking this is just an operative concern. If you don't want that your user set vhosts like this then you will have to think to a way to do this. I'm not sure that couchdb should concern about it, especially since you can whitelist _config. You could also create your own _config handler that filter entries . Since I wrote the whitelist feature, yes I am aware how I could work around supporting this. I have operational concerns. However I am simply asking that the community think very hard about what this means before permanently committing to it. Specifically, the fact is CouchDB is a fantastic platform with very, very few good applications. CouchDB is years ahead of the popular couchapps with respect to polish and features. My point is, are we bending CouchDB in order to cover for the fact that there is no good App Admin tool out there? Maybe the answer is no. Okay, fine, as long as the decision is deliberated and understood by everybody, cool! I do agree about two things: 1. It is difficult for beginners to develop on localhost:5984 and then push to couch.domain.tld. vhost is managed separate from the ddoc and even the DB, so it does not replicate. It totally sucks. 2. It is hard to manage vhosts. You have cURL and you have Futon, which did not even work correctly in 1.0.0. It would bother me if I do not know which Host header to reply to without inspecting all database and ddocs. My preference is dumb vhosts and a smart rewriter. For example, if the rewrite rule could see the req object and Host header, it could redirect to the correct db, ddoc, and path. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 23:53, Noah Slater nsla...@apache.org wrote: On 19 Aug 2010, at 17:48, Benoit Chesneau wrote: 3. Everybody knows them that's not true. http://xkcd.com/208/ To answer to this reinventing . We had long discussions on how to manage rewriting in couchapps. Some included regexp, we fall in the current system. Ie pattern matching because it was a lot easier to understand and *simple*. SInce the system is already in place, I wanted to reuse it too, there is no need to have 2 dofferent ways to handle rewriting. I would like to keep it *simple*, that's the key. We're approaching bike shed territory... :D Sure. This is my final statement on the matter. My feeling is when you need * pattern matching (the concept, not Erlang) * capturing substrings * building new strings based on the captured parts * Understood by *most* programmers and sysadmins is lagniappe Then the burden of proof is on the person who says regular expressions are inferior to an off-the-cuff implementation. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
My feeling is when you need * pattern matching (the concept, not Erlang) * capturing substrings * building new strings based on the captured parts * Understood by *most* programmers and sysadmins is lagniappe what is not understandable in $val1.test.$val2.domain.tld = /$val1/$val2 ? which is like [val1, test, val2, domain, tld] compared to (.*)\.test\.(.*).domain.tld = /$1/*2 sorry but I think the second one not really friendly. - benoit
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 7:00 PM, Jason Smith j...@couch.io wrote: On Thu, Aug 19, 2010 at 22:23, Benoit Chesneau bchesn...@gmail.com wrote: To answer in a more generic way. As a sys admin or operatives, you are already habit to vhosts or Locations with http servers. This is the same system here. Nothing new, just a syntax different. I think also there is 2 views of couchdb in oposition here. One is about managing couchdb in multi mass hosting other is to see couchdb as a standalone db that could be used on any device. Back around 0.9, there was a huge discussion about transactional bulk inserts. The prevailing view was that CouchDB does not show a behavior unless it can show that behavior in all possible deployments. I am asking if the same logic applies here. In the future when every device has CouchDB and every ISP runs it and every carrier caches it and everything, apps need to work there too. That is why I am attracted to a simple vhost implementation. This feature isn't yet implemented. It only works for domain names. You don't need to use a wildcard. If you're worried about your users and the fact they could use this feature, I am thinking this is just an operative concern. If you don't want that your user set vhosts like this then you will have to think to a way to do this. I'm not sure that couchdb should concern about it, especially since you can whitelist _config. You could also create your own _config handler that filter entries . Since I wrote the whitelist feature, yes I am aware how I could work around supporting this. I have operational concerns. However I am simply asking that the community think very hard about what this means before permanently committing to it. Specifically, the fact is CouchDB is a fantastic platform with very, very few good applications. CouchDB is years ahead of the popular couchapps with respect to polish and features. My point is, are we bending CouchDB in order to cover for the fact that there is no good App Admin tool out there? Maybe the answer is no. Okay, fine, as long as the decision is deliberated and understood by everybody, cool! I do agree about two things: 1. It is difficult for beginners to develop on localhost:5984 and then push to couch.domain.tld. vhost is managed separate from the ddoc and even the DB, so it does not replicate. It totally sucks. 2. It is hard to manage vhosts. You have cURL and you have Futon, which did not even work correctly in 1.0.0. It would bother me if I do not know which Host header to reply to without inspecting all database and ddocs. My preference is dumb vhosts and a smart rewriter. For example, if the rewrite rule could see the req object and Host header, it could redirect to the correct db, ddoc, and path. A couchapp should be domain independant, this is the principle of a couchapp . So I can replicate anywhere and not only in centralizedhost.com . Following this principle, it sound weird to set an hostname in the CouchApp. About difficulty to handle couchapp behoind a vhost or not, it's already handled by current system : You can set a rewrite rule to always use the database or detected if you were rewritten by comparing req.requested_path vs req.path.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
A couchapp should be domain independant, this is the principle of a s/domain/couchdb node
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Fri, Aug 20, 2010 at 00:13, Benoit Chesneau bchesn...@gmail.com wrote: A couchapp should be domain independant, this is the principle of a couchapp . So I can replicate anywhere and not only in centralizedhost.com . Following this principle, it sound weird to set an hostname in the CouchApp. That is true. But partially, the reason couchapps run immediately after replication is because all couchapps are still very simple. In the future they will be like The mature PHP apps. First you copy to the target. Then you run a one-time config to input your email address, site name, theme preferences, etc. etc. In there might be the vhost/rewrite questions. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 7:22 PM, Jason Smith j...@couch.io wrote: On Fri, Aug 20, 2010 at 00:13, Benoit Chesneau bchesn...@gmail.com wrote: A couchapp should be domain independant, this is the principle of a couchapp . So I can replicate anywhere and not only in centralizedhost.com . Following this principle, it sound weird to set an hostname in the CouchApp. That is true. But partially, the reason couchapps run immediately after replication is because all couchapps are still very simple. In the future they will be like The mature PHP apps. First you copy to the target. Then you run a one-time config to input your email address, site name, theme preferences, etc. etc. In there might be the vhost/rewrite questions. there is no reason to not keep the simplicity while the couchapps feature grow. And I personnaly hope that CouchDB will help to remove the need of a centralized hosting and just use these services as a facility to put online for a time our data. But that's just the way I see it. Today it's already possible to had an hostname to any couchapp and write an handler listening on each dbs to get updates in ddocs and then set hostname. What could be interresting is y to ease management of modules in couch so you can add your mod_vhost like you can do on apache. - benoit
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
But that's just the way I see it. Today it's already possible to had s/had/add sorry for the typos.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Fri, Aug 20, 2010 at 00:37, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 7:22 PM, Jason Smith j...@couch.io wrote: On Fri, Aug 20, 2010 at 00:13, Benoit Chesneau bchesn...@gmail.com wrote: A couchapp should be domain independant, this is the principle of a couchapp . So I can replicate anywhere and not only in centralizedhost.com . Following this principle, it sound weird to set an hostname in the CouchApp. That is true. But partially, the reason couchapps run immediately after replication is because all couchapps are still very simple. In the future they will be like The mature PHP apps. First you copy to the target. Then you run a one-time config to input your email address, site name, theme preferences, etc. etc. In there might be the vhost/rewrite questions. there is no reason to not keep the simplicity while the couchapps feature grow. And I personnaly hope that CouchDB will help to remove the need of a centralized hosting and just use these services as a facility to put online for a time our data. But that's just the way I see it. Today it's already possible to had an hostname to any couchapp and write an handler listening on each dbs to get updates in ddocs and then set hostname. What could be interresting is y to ease management of modules in couch so you can add your mod_vhost like you can do on apache. I am also very interested in that. It is very easy with Erlang modules. I think the only problem is not many people know Erlang. When I wrote my first auth handler, it was I think 15 lines of code. And I edited local.ini. Voila! -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 10:59 AM, Jason Smith j...@couch.io wrote: On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau bchesn...@gmail.com wrote: Could you explain me how it's impossible compared to previous behaviour ? It doesn't change anything technically. Please post all your concern and a way to reproduce , I will have a look on it. Though here hosting 50 couch - trunk behingd couchdbproxy works. tested yesterday. ## The top priority question: How can proxies managed by the sysadmin or network admin know what to do? Now, vhost is explicit. Anybody with permission can query /_config/vhosts for all couches. With wildcards, e.g. */blog, it is impossible to know all domains which the web server handles. When a query for fooapp.foodb.mydomain.tld arrives, which couch should handle it? CouchDB adoption is growing. The network, system, and programming responsibilities are becoming different people. It needs to allow everybody to do their job. Can you describe this in more detail? I don't think I understand your concerns very well. I'm not familiar with hosting setups so maybe I'm just missing something obvious. I just can't figure out why a network administrator would need to reverse engineer the vhost settings. As to the bike shedding on syntax I can only say that the non-regexp syntax looked fine to me. Though I understand the complaint about inventing syntax, instead of jumping for regexp's I would probably take a look at WebMachine's dispatcher mechanism as it reuses Erlang which I always found quite nifty. And a side point on the regexp syntax you posted: (.*).(.*).mydomain.tld - /$2/_design/$1/_rewrite This is a pretty good example of why regexps really aren't such a hot idea. I'll give 10 internets to the first person that figures out how that pattern matches this domain: blog.davisp.mydomain.tld One hint is that it wouldn't rewrite to /davisp/_design/blog/_rewrite. And because its always funny: Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. - Jamie Zawinski HTH, Paul Davis
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
I'll admit I'm a little lost here too. What is the change to $foo supposed to allow for, and what is the downside to having it? I think the example: $app.$db.example.com = /$db/_design/$app/_rewrite is actually pretty compelling *as a convenience feature.* However, Jason is arguing that the convenience is putting some smarts in a place that would be better off dumb. This is the same argument that the Google/Verizon stuff is about: should the middleware part of the stack be smart or dumb? So far, dumb has been the clear winner in the general case, even when it is a pain in the specific case. We should reflect on that before we jump to making this change. My top concern with all of this vhost stuff is much more basic, and I think needs to be addressed before we think about adding convenience features: On localhost, there is no such thing as a Domain Name (unless you are the type to hack your /etc/hosts, which is like 0.01% of people). KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of running on localhost. Until we solve this issue I'm not much interested in refining the existing vhost stuff. Chris On Aug 19, 2010, at 11:43 AM, Paul Davis wrote: On Thu, Aug 19, 2010 at 10:59 AM, Jason Smith j...@couch.io wrote: On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau bchesn...@gmail.com wrote: Could you explain me how it's impossible compared to previous behaviour ? It doesn't change anything technically. Please post all your concern and a way to reproduce , I will have a look on it. Though here hosting 50 couch - trunk behingd couchdbproxy works. tested yesterday. ## The top priority question: How can proxies managed by the sysadmin or network admin know what to do? Now, vhost is explicit. Anybody with permission can query /_config/vhosts for all couches. With wildcards, e.g. */blog, it is impossible to know all domains which the web server handles. When a query for fooapp.foodb.mydomain.tld arrives, which couch should handle it? CouchDB adoption is growing. The network, system, and programming responsibilities are becoming different people. It needs to allow everybody to do their job. Can you describe this in more detail? I don't think I understand your concerns very well. I'm not familiar with hosting setups so maybe I'm just missing something obvious. I just can't figure out why a network administrator would need to reverse engineer the vhost settings. As to the bike shedding on syntax I can only say that the non-regexp syntax looked fine to me. Though I understand the complaint about inventing syntax, instead of jumping for regexp's I would probably take a look at WebMachine's dispatcher mechanism as it reuses Erlang which I always found quite nifty. And a side point on the regexp syntax you posted: (.*).(.*).mydomain.tld - /$2/_design/$1/_rewrite This is a pretty good example of why regexps really aren't such a hot idea. I'll give 10 internets to the first person that figures out how that pattern matches this domain: blog.davisp.mydomain.tld One hint is that it wouldn't rewrite to /davisp/_design/blog/_rewrite. And because its always funny: Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. - Jamie Zawinski HTH, Paul Davis
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 9:28 PM, J Chris Anderson jch...@apache.org wrote: My top concern with all of this vhost stuff is much more basic, and I think needs to be addressed before we think about adding convenience features: On localhost, there is no such thing as a Domain Name (unless you are the type to hack your /etc/hosts, which is like 0.01% of people). KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of running on localhost. Until we solve this issue I'm not much interested in refining the existing vhost stuff. Where is the issue ? :)
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Fri, Aug 20, 2010 at 01:43, Paul Davis paul.joseph.da...@gmail.comwrote: CouchDB adoption is growing. The network, system, and programming responsibilities are becoming different people. It needs to allow everybody to do their job. Can you describe this in more detail? I don't think I understand your concerns very well. I'm not familiar with hosting setups so maybe I'm just missing something obvious. I just can't figure out why a network administrator would need to reverse engineer the vhost settings. Obviously I think a lot about CouchDB deployments where the couchapp developer is neither the sysadmin responsible for running the couchdb program, nor the network admin responsible for moving the bytes around. For example, I wrote the config whitelist feature because the, let's say, DBA should not have the ability to change the couchdb listen address or port in some operational situations. In a common reverse-proxy situation, you get a request and you look at the Host header and *maybe* the path and you decide where to route that query to. Well now with DBAs having a big old time with vhosts, the reverse proxy needs to know what vhosts have been configured so when it encounteres Host: blog.example.com it can say, Oh right, blog.example.com was vhosted in Bob's CouchDB server, so I will route it there. The only way I think, let's call it the CouchDB hosting community knows how to do that is to query _config/vhosts for all the couches and populate the routing tables with those results. So I am not rejecting Benoit's idea, just saying that it will add burden to people who maintain reverse proxies in front of CouchDB. As to the bike shedding on syntax I can only say that the non-regexp syntax looked fine to me. Though I understand the complaint about inventing syntax, instead of jumping for regexp's I would probably take a look at WebMachine's dispatcher mechanism as it reuses Erlang which I always found quite nifty. And a side point on the regexp syntax you posted: (.*).(.*).mydomain.tld - /$2/_design/$1/_rewrite This is a pretty good example of why regexps really aren't such a hot idea. I'll give 10 internets to the first person that figures out how that pattern matches this domain: I did simplify it for rhetorical purposes. I knew the dots didn't match themselves but I usually try to get away with the greedy matching before falling back to un-greedy. Of course, a hypothetical regex implementation would use Erlang's re module which is reasonably bug-free. As a sysadmin that gives me comfort. And when I discover a bug in my regular expression, there are countless resources. On the other hand, I am identifying the frustration that programmers and sysadmins get when they encounter an obviously new and unknown syntax. In other words: the principle of least surprise. CouchDB is HTTP for that reason. CouchDB is REST for that reason. View indexes are the same as databases for that reason. Applications are also documents for that reason. Replication is just another client for that reason. (However in an offline email I made it clear that I will happily defer to the implementation which exists!) And because its always funny: Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. - Jamie Zawinski Very droll. But the point is given too much credit due to its clever presentation. My first day at Couchio I heard Mikeal say, the problem with domain-specific languages is now everybody thinks he's a fucking language designer. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Fri, Aug 20, 2010 at 02:28, J Chris Anderson jch...@apache.org wrote: KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of running on localhost. Until we solve this issue I'm not much interested in refining the existing vhost stuff. Many apologies but I'm having trouble following. Why can't a couchapp run on localhost? Already you can vhost localhost:5984 to your app's rewriter. Is the problem because that locks you out of Futon? (localhost.localdomain:5984 still work, as does machine_name.local on OSX or Ubuntu, or if you've installed Avahi or Bonjour) -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Aug 19, 2010, at 1:25 PM, Jason Smith wrote: On Fri, Aug 20, 2010 at 02:28, J Chris Anderson jch...@apache.org wrote: KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of running on localhost. Until we solve this issue I'm not much interested in refining the existing vhost stuff. Many apologies but I'm having trouble following. Why can't a couchapp run on localhost? Already you can vhost localhost:5984 to your app's rewriter. Is the problem because that locks you out of Futon? (localhost.localdomain:5984 still work, as does machine_name.local on OSX or Ubuntu, or if you've installed Avahi or Bonjour) I'm not that fancy. My point is that if you have an app that requires a vhost to work, then you have to do some machine level configuration to get more than one (or maybe 2) vhosts, from a standard issue Mac or Windows box. You can't ask grandma to do that. If the vhost directive allowed matching on parts of the path, then you could have */foobar = /foo/_design/bar/_rewrite and then the user could just visit localhost:5984/foobar and have it work. I described this in more detail here https://issues.apache.org/jira/browse/COUCHDB-230 Because all the configuration happens in the couch, the couchapp can self configure. As soon as you start requiring people who don't know what a URL is to edit /etc/hosts, you're hosed. Chris -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 10:20 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, Aug 19, 2010 at 9:28 PM, J Chris Anderson jch...@apache.org wrote: My top concern with all of this vhost stuff is much more basic, and I think needs to be addressed before we think about adding convenience features: On localhost, there is no such thing as a Domain Name (unless you are the type to hack your /etc/hosts, which is like 0.01% of people). KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of running on localhost. Until we solve this issue I'm not much interested in refining the existing vhost stuff. Where is the issue ? :) Can you give an example of CouchApp which is designed to require vhosts , which isn't really needed today even when using _rewrite. - benoit
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 10:31 PM, J Chris Anderson jch...@apache.org wrote: On Aug 19, 2010, at 1:25 PM, Jason Smith wrote: On Fri, Aug 20, 2010 at 02:28, J Chris Anderson jch...@apache.org wrote: KEY POINT: Any CouchApp which is designed to require vhosts is automatically not capable of running on localhost. Until we solve this issue I'm not much interested in refining the existing vhost stuff. Many apologies but I'm having trouble following. Why can't a couchapp run on localhost? Already you can vhost localhost:5984 to your app's rewriter. Is the problem because that locks you out of Futon? (localhost.localdomain:5984 still work, as does machine_name.local on OSX or Ubuntu, or if you've installed Avahi or Bonjour) I'm not that fancy. My point is that if you have an app that requires a vhost to work, then you have to do some machine level configuration to get more than one (or maybe 2) vhosts, from a standard issue Mac or Windows box. You can't ask grandma to do that. If the vhost directive allowed matching on parts of the path, then you could have */foobar = /foo/_design/bar/_rewrite and then the user could just visit localhost:5984/foobar and have it work. I described this in more detail here https://issues.apache.org/jira/browse/COUCHDB-230 Because all the configuration happens in the couch, the couchapp can self configure. As soon as you start requiring people who don't know what a URL is to edit /etc/hosts, you're hosed. Chris updated the ticket.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12900448#action_12900448 ] Benoit Chesneau commented on COUCHDB-230: - Following thread on ml Imo Path alias shouln't be in vhosts but in its own section since this is not a vhost but more an aliases section is we follow the apache server wording. 3 questions anyway : 1) What happend anyway if a couchapp is self configuring but another app with same name already exist ? 2) What happend if path replace db path 3) security concern how to make sure a couchapp won't self configure even if the user is connected as admin ? I think anyway for 2, that having it in /_root or /_/ would be better so api always available. Or at least, this prefix should be configurable (/ , /app or watever). Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Fri, Aug 20, 2010 at 03:31, J Chris Anderson jch...@apache.org wrote:
My point is that if you have an app that requires a vhost to work, then you
have to do some machine level configuration to get more than one (or maybe
2) vhosts, from a standard issue Mac or Windows box. You can't ask grandma
to do that.
I'm not clear on requires. You can still go to /db/_design/app/_rewrite/
without vhost rules.
If the vhost directive allowed matching on parts of the path, then you
could have */foobar = /foo/_design/bar/_rewrite and then the user could just
visit localhost:5984/foobar and have it work.
That's a cool feature. But it has ramifications for reverse proxies. If the
proxy gets a request for example.com/foobar it will not easily know where to
send it because every couch on the back end has the same vhost setting:
*/foobar. In other words, you could no longer use the union of all
_config/vhosts as a registry for all domains to serve. I brought up
transactional _bulk_inserts because the conclusion was, if it works in any
situation, it must work in all situations. But yes, the situations are
different.
Since the path queried is in the HTTP request, reverse proxies have no
problem. Unless you are rewriting. A rewriter can change that path, which
could trigger a different vhost setting, or could it? And if so, is there
impact on secure_rewrites?
vhost: */sofa = /blog/_design/sofa/_rewrite
rewrite: {from: pages/*, to:../../../pages/*}
vhost: */pages = /pages/_design/pages/_rewrite
This is contrived, I'm just working this out. But is the expectation here
that /sofa/pages/foo would return the foo wiki page or 404?
--
Jason Smith
Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 4:21 PM, Jason Smith j...@couch.io wrote: On Fri, Aug 20, 2010 at 01:43, Paul Davis paul.joseph.da...@gmail.comwrote: CouchDB adoption is growing. The network, system, and programming responsibilities are becoming different people. It needs to allow everybody to do their job. Can you describe this in more detail? I don't think I understand your concerns very well. I'm not familiar with hosting setups so maybe I'm just missing something obvious. I just can't figure out why a network administrator would need to reverse engineer the vhost settings. Obviously I think a lot about CouchDB deployments where the couchapp developer is neither the sysadmin responsible for running the couchdb program, nor the network admin responsible for moving the bytes around. For example, I wrote the config whitelist feature because the, let's say, DBA should not have the ability to change the couchdb listen address or port in some operational situations. In a common reverse-proxy situation, you get a request and you look at the Host header and *maybe* the path and you decide where to route that query to. Well now with DBAs having a big old time with vhosts, the reverse proxy needs to know what vhosts have been configured so when it encounteres Host: blog.example.com it can say, Oh right, blog.example.com was vhosted in Bob's CouchDB server, so I will route it there. The only way I think, let's call it the CouchDB hosting community knows how to do that is to query _config/vhosts for all the couches and populate the routing tables with those results. So I am not rejecting Benoit's idea, just saying that it will add burden to people who maintain reverse proxies in front of CouchDB. Still confused. A couchapp developer shouldn't require any sort of configuration because that's not under their control. For a couchapp to be couchappy, its going to be barred from *requiring* such configuration or it'll never work on the wide number of clients that would be expected to host them as Chris points out. As to the network admin side of things I'm confused why they would ever trust routing tables to something they had no control over. I'd think that they'd either treat them as the port and address settings as specified by operations, or they'd just ignore them and route based on OOB information. For my curiosity, what happens when a vhost setting is wrong? Ie, Bob set a vhost to be blog.gene.com which should really go to Gene's couch? Or when there's no vhost set at all? Or when a request comes into a vhost that's unknown? As to the bike shedding on syntax I can only say that the non-regexp syntax looked fine to me. Though I understand the complaint about inventing syntax, instead of jumping for regexp's I would probably take a look at WebMachine's dispatcher mechanism as it reuses Erlang which I always found quite nifty. And a side point on the regexp syntax you posted: (.*).(.*).mydomain.tld - /$2/_design/$1/_rewrite This is a pretty good example of why regexps really aren't such a hot idea. I'll give 10 internets to the first person that figures out how that pattern matches this domain: I did simplify it for rhetorical purposes. I knew the dots didn't match themselves but I usually try to get away with the greedy matching before falling back to un-greedy. Of course, a hypothetical regex implementation would use Erlang's re module which is reasonably bug-free. As a sysadmin that gives me comfort. And when I discover a bug in my regular expression, there are countless resources. On the other hand, I am identifying the frustration that programmers and sysadmins get when they encounter an obviously new and unknown syntax. In other words: the principle of least surprise. CouchDB is HTTP for that reason. CouchDB is REST for that reason. View indexes are the same as databases for that reason. Applications are also documents for that reason. Replication is just another client for that reason. (However in an offline email I made it clear that I will happily defer to the implementation which exists!) And because its always funny: Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. - Jamie Zawinski Very droll. But the point is given too much credit due to its clever presentation. My first day at Couchio I heard Mikeal say, the problem with domain-specific languages is now everybody thinks he's a fucking language designer. -- Jason Smith Couchio Hosting
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Thu, Aug 19, 2010 at 4:57 PM, Jason Smith j...@couch.io wrote:
On Fri, Aug 20, 2010 at 03:31, J Chris Anderson jch...@apache.org wrote:
My point is that if you have an app that requires a vhost to work, then you
have to do some machine level configuration to get more than one (or maybe
2) vhosts, from a standard issue Mac or Windows box. You can't ask grandma
to do that.
I'm not clear on requires. You can still go to /db/_design/app/_rewrite/
without vhost rules.
If the vhost directive allowed matching on parts of the path, then you
could have */foobar = /foo/_design/bar/_rewrite and then the user could just
visit localhost:5984/foobar and have it work.
That's a cool feature. But it has ramifications for reverse proxies. If the
proxy gets a request for example.com/foobar it will not easily know where to
send it because every couch on the back end has the same vhost setting:
*/foobar. In other words, you could no longer use the union of all
_config/vhosts as a registry for all domains to serve. I brought up
transactional _bulk_inserts because the conclusion was, if it works in any
situation, it must work in all situations. But yes, the situations are
different.
Since the path queried is in the HTTP request, reverse proxies have no
problem. Unless you are rewriting. A rewriter can change that path, which
could trigger a different vhost setting, or could it? And if so, is there
impact on secure_rewrites?
vhost: */sofa = /blog/_design/sofa/_rewrite
rewrite: {from: pages/*, to:../../../pages/*}
vhost: */pages = /pages/_design/pages/_rewrite
This is contrived, I'm just working this out. But is the expectation here
that /sofa/pages/foo would return the foo wiki page or 404?
--
Jason Smith
Couchio Hosting
I think this is starting to muddy the waters between vhost matching
and path rewriting. AFAIK, a rewrite can't rewrite itself to a
different domain which is good. It could as you point out rewrite to
match another rewrite pattern, but from the code I skimmed earlier I
think we only allow a single rewrite before we hit the internal
handling. Ie, it could conceivably be made recursive to allow
rewriting rewritten urls, but that's going to get into possible abuse
land.
Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
On Fri, Aug 20, 2010 at 04:02, Paul Davis paul.joseph.da...@gmail.comwrote: Still confused. A couchapp developer shouldn't require any sort of configuration because that's not under their control. For a couchapp to be couchappy, its going to be barred from *requiring* such configuration or it'll never work on the wide number of clients that would be expected to host them as Chris points out. Indeed. However I think in practice, couch app developers demand that the URL looks reasonable. Benoit mentioned that vhost and _rewrite are already becoming very popular with developers. For my curiosity, what happens when a vhost setting is wrong? Ie, Bob set a vhost to be blog.gene.com which should really go to Gene's couch? Or when there's no vhost set at all? Or when a request comes into a vhost that's unknown? There is a pattern to handle that. Bob has a canonical address, bob.service.com, assigned at signup. Bob can add whatever vhost he wants. However service.com will only honor those for which a DNS query returns a CNAME back to bob.service.com. Since bob cannot modify DNS records in gene.com, he cannot steal blog.gene.com. -- Jason Smith Couchio Hosting
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899770#action_12899770 ] Benoit Chesneau commented on COUCHDB-230: - actually you could already do : example.com/foobar = /foo/_design/bar/_rewrite *.website.com/foobar = /foo/_design/bar/_rewrite localhost:5984/bazbam = /whatever and : $vhost.example.com = /$vhost even $app.$vhost.example.com /$vhost/_design/$app/_rewrite for the path based reouting we could likely introduce that too, but it need some code rewrite to share code with rewriter. For local usage though I was thinking that not allowing /pathname but only /_root/pathname would have been better to not be in conflict with the current API. [ Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899954#action_12899954 ] Benoit Chesneau commented on COUCHDB-230: - the $ stuff is already in the code with the vhost refactoring. The only thing to add is this path stuff which is a little more complex btw. I will work on it this week, it will likely land on friday. - benoit Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899394#action_12899394 ] Benoit Chesneau commented on COUCHDB-230: - I would like to develop this feature but I'm not sure we should be on / ? My idee is to do /_root/some-location - /rewrittent-location where _root is customizable via the ini. Thoughts ? Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899421#action_12899421 ] Jan Lehnardt commented on COUCHDB-230: -- I think pointing a vhost at a rewrite function gets you there today. I like the idea of 127.0.0.1:5984/ to always give you the raw CouchDB API. Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899449#action_12899449 ] Benoit Chesneau commented on COUCHDB-230: - vhosts can only work well with vhosts.Maybe it's overkill but I thought it would be interresting for users to have a shott access to apps rather than pointing them to /dbname/_design/somedesign/_rewrite or smth else. Instead having smth like /_/somedesign would make things easier I think. Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12899656#action_12899656 ] Chris Anderson commented on COUCHDB-230: I was thinking we could just extend the current vhosts api so that: [vhosts] example.com/foobar = /foo/_design/bar/_rewrite it would be up to the admin to avoid stomping on existing database names. I am more than happy to allow them to live with that risk. Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.2 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-230) Add Support for Rewritable URL
[ https://issues.apache.org/jira/browse/COUCHDB-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888454#action_12888454 ] Randall Leeds commented on COUCHDB-230: --- Isn't this fixed? Add Support for Rewritable URL -- Key: COUCHDB-230 URL: https://issues.apache.org/jira/browse/COUCHDB-230 Project: CouchDB Issue Type: New Feature Reporter: Patrick Aljord Fix For: 1.0.1 It would be good if couchdb would allow to rewrite urls so that instead of having to write that: http://127.0.0.1:5984/blogdb/_design/sofa/account.html I could just write: http://127.0.0.1:5984/blogdb/account It could be done with the web server but having the rewritten rules in the db would make it a bit easier for replication so we don't have to write the rules on each web server where a db gets replicated. Here are a few propositions from davisp: davisp alisdair: how so? rewriting urls should be in _design documents, since they're in _design docs they should be limited to per db namespaces davisp bobesponja: I don't know that anyone has looked at it seriously, but my first guess is that we'd just make a _design/doc urls member that's a list of regex's and targets as is fairly standard practice davisp bobesponja: or perhaps, regex's - erlang handler davisp the second might not be as fun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
