[jira] [Commented] (COUCHDB-1213) proxy with external api doesn't work
[
https://issues.apache.org/jira/browse/COUCHDB-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060098#comment-13060098
]
Till Klampaeckel commented on COUCHDB-1213:
---
I +1 this +1
> proxy with external api doesn't work
>
>
> Key: COUCHDB-1213
> URL: https://issues.apache.org/jira/browse/COUCHDB-1213
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Till Klampaeckel
> Labels: patch, proxy
>
> As discussed on IRC, I'm trying to use an external web API, but every request
> to the handler produces an infinite loop.
> This is most likely due to not passing on the correct Host header.
> Here's an example:
> _google = {couch_httpd_proxy, handle_proxy_req,
> <<"http://www.google.com/ig";>>}
> Then request with:
> curl -L -X GET
> http://127.0.0.1:5984/_google/calculator?hl=en&q=100EUR%3D%3FAUD
> Paul Davis did a quick patch: http://friendpaste.com/62T88HOYw8QyaoIJoXEGXr
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1213) proxy with external api doesn't work
proxy with external api doesn't work
Key: COUCHDB-1213
URL: https://issues.apache.org/jira/browse/COUCHDB-1213
Project: CouchDB
Issue Type: Bug
Affects Versions: 1.1
Reporter: Till Klampaeckel
As discussed on IRC, I'm trying to use an external web API, but every request
to the handler produces an infinite loop.
This is most likely due to not passing on the correct Host header.
Here's an example:
_google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com/ig";>>}
Then request with:
curl -L -X GET http://127.0.0.1:5984/_google/calculator?hl=en&q=100EUR%3D%3FAUD
Paul Davis did a quick patch: http://friendpaste.com/62T88HOYw8QyaoIJoXEGXr
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COUCHDB-1069) Init script report "OK" even when there's already another CouchDB process on the same port.
Init script report "OK" even when there's already another CouchDB process on the same port. --- Key: COUCHDB-1069 URL: https://issues.apache.org/jira/browse/COUCHDB-1069 Project: CouchDB Issue Type: Bug Affects Versions: 1.0.2 Environment: Ubuntu Reporter: Till Klampaeckel Priority: Minor I had another CouchDB installation running which I installed through aptitude. When I compiled couchdb from source and started it through the included init script, the processes were running and the start script reported OK. However, on port 5984 I had the other install running. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COUCHDB-865) More ./configure options
More ./configure options Key: COUCHDB-865 URL: https://issues.apache.org/jira/browse/COUCHDB-865 Project: CouchDB Issue Type: New Feature Affects Versions: 1.0.1, 0.11.2 Reporter: Till Klampaeckel So for example ob Linux, this defaults file is written when CouchDB is installed: COUCHDB_USER=couchdb COUCHDB_STDOUT_FILE=/dev/null COUCHDB_STDERR_FILE=/dev/null COUCHDB_RESPAWN_TIMEOUT=5 COUCHDB_OPTIONS= I'd like to be able to influence these things with ./configure. ./configure --couchdb-user=root --couchdb-respawn-timeout=10 --couchdb-port=80 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-782) Restarting replication
[
https://issues.apache.org/jira/browse/COUCHDB-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875159#action_12875159
]
Till Klampaeckel commented on COUCHDB-782:
--
Until I find time for the wiki:
The mechanism does not just depend on the host per se, all the following URIs
are different to CouchDB even though they point to the same system:
http://foo:b...@localhost:5984/citations
http://localhost:5984/citations
@Randall
While you're at it doing UUIDs for databases, do you think it would be possible
to do a UUID for a server as well? It could be exposed with the version. It
would be very useful in large scale setups for monitoring etc.. E.g. to easily
tell shards apart, etc.. Vs. building external "logic" that revolves around
hostnames, port numbers or different something.
> Restarting replication
> ---
>
> Key: COUCHDB-782
> URL: https://issues.apache.org/jira/browse/COUCHDB-782
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.10
> Environment: Ubuntu, 9.10
>Reporter: Till Klampaeckel
>
> So we had to restart replication on a server and here's something I noticed.
> At first I restarted the replication via the following command from localhost:
> curl -X POST -d '{"source":"http://localhost:5984/foo";,
> "target":"http://remote:5984/foo"}' http://localhost:5984/_replicate
> In response, futon stats:
> W Processed source update #176841152
> That part is great.
> Last night I did not have immediate access to the shell so I restarted
> replication from remote (through curl on my mobile):
> curl -X POST -d '{"source":"http://user:p...@public.host:5984/foo";,
> "target":"http://remote:5984/foo"}'
> http://user:p...@pubic.host:5984/_replicate
> The response in futon this morning:
> W Processed source update #1066
> ... and it kept sitting there like it was stalled and only continued in
> smaller increments.
> I restarted CouchDB and restarted from localhost - instant jump to 176
> million.
> I'm just wondering what might be different accept for that one is against the
> public interface, vs. localhost. I'd assume that replication behaves the same
> regardless.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-782) Restarting replication
[
https://issues.apache.org/jira/browse/COUCHDB-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874666#action_12874666
]
Till Klampaeckel commented on COUCHDB-782:
--
I guess I agree that it's important.
This is probably not an issue for installs on a smaller scale but gets annoying
when you're in for "moar".
> Restarting replication
> ---
>
> Key: COUCHDB-782
> URL: https://issues.apache.org/jira/browse/COUCHDB-782
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.10
> Environment: Ubuntu, 9.10
>Reporter: Till Klampaeckel
>
> So we had to restart replication on a server and here's something I noticed.
> At first I restarted the replication via the following command from localhost:
> curl -X POST -d '{"source":"http://localhost:5984/foo";,
> "target":"http://remote:5984/foo"}' http://localhost:5984/_replicate
> In response, futon stats:
> W Processed source update #176841152
> That part is great.
> Last night I did not have immediate access to the shell so I restarted
> replication from remote (through curl on my mobile):
> curl -X POST -d '{"source":"http://user:p...@public.host:5984/foo";,
> "target":"http://remote:5984/foo"}'
> http://user:p...@pubic.host:5984/_replicate
> The response in futon this morning:
> W Processed source update #1066
> ... and it kept sitting there like it was stalled and only continued in
> smaller increments.
> I restarted CouchDB and restarted from localhost - instant jump to 176
> million.
> I'm just wondering what might be different accept for that one is against the
> public interface, vs. localhost. I'd assume that replication behaves the same
> regardless.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-782) Restarting replication
[
https://issues.apache.org/jira/browse/COUCHDB-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Klampaeckel updated COUCHDB-782:
-
Description:
So we had to restart replication on a server and here's something I noticed.
At first I restarted the replication via the following command from localhost:
curl -X POST -d '{"source":"http://localhost:5984/foo";,
"target":"http://remote:5984/foo"}' http://localhost:5984/_replicate
In response, futon stats:
W Processed source update #176841152
That part is great.
Last night I did not have immediate access to the shell so I restarted
replication from remote (through curl on my mobile):
curl -X POST -d '{"source":"http://user:p...@public.host:5984/foo";,
"target":"http://remote:5984/foo"}' http://user:p...@pubic.host:5984/_replicate
The response in futon this morning:
W Processed source update #1066
... and it kept sitting there like it was stalled and only continued in smaller
increments.
I restarted CouchDB and restarted from localhost - instant jump to 176 million.
I'm just wondering what might be different accept for that one is against the
public interface, vs. localhost. I'd assume that replication behaves the same
regardless.
was:
So we had to restart replication on a server and here's something I noticed.
At first I restarted the replication via the following command from localhost:
curl -X POST -d '{"source":"http://localhost:5984/foo";,
"target":"http://remote:5984/foo"}' http://localhost:5984/_replicate
In response, futon stats:
W Processed source update #176841152
That part is great.
Last night I did not have immediate access to the shell so I restarted
replication from remote:
curl -X POST -d '{"source":"http://user:p...@public.host:5984/foo";,
"target":"http://remote:5984/foo"}' http://user:p...@pubic.host:5984/_replicate
The response in futon this morning:
W Processed source update #1066
... and it kept sitting there like it was stalled and only continue in smaller
increments.
I restarted CouchDB and restarted from localhost - instant jump to 176 million.
I'm just wondering what might be different accept for that one is against the
public interface, vs. localhost. I'd assume that replication behaves the same
regardless.
Spelling!
> Restarting replication
> ---
>
> Key: COUCHDB-782
> URL: https://issues.apache.org/jira/browse/COUCHDB-782
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.10
> Environment: Ubuntu, 9.10
>Reporter: Till Klampaeckel
>
> So we had to restart replication on a server and here's something I noticed.
> At first I restarted the replication via the following command from localhost:
> curl -X POST -d '{"source":"http://localhost:5984/foo";,
> "target":"http://remote:5984/foo"}' http://localhost:5984/_replicate
> In response, futon stats:
> W Processed source update #176841152
> That part is great.
> Last night I did not have immediate access to the shell so I restarted
> replication from remote (through curl on my mobile):
> curl -X POST -d '{"source":"http://user:p...@public.host:5984/foo";,
> "target":"http://remote:5984/foo"}'
> http://user:p...@pubic.host:5984/_replicate
> The response in futon this morning:
> W Processed source update #1066
> ... and it kept sitting there like it was stalled and only continued in
> smaller increments.
> I restarted CouchDB and restarted from localhost - instant jump to 176
> million.
> I'm just wondering what might be different accept for that one is against the
> public interface, vs. localhost. I'd assume that replication behaves the same
> regardless.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-782) Restarting replication
Restarting replication
---
Key: COUCHDB-782
URL: https://issues.apache.org/jira/browse/COUCHDB-782
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 0.10
Environment: Ubuntu, 9.10
Reporter: Till Klampaeckel
So we had to restart replication on a server and here's something I noticed.
At first I restarted the replication via the following command from localhost:
curl -X POST -d '{"source":"http://localhost:5984/foo";,
"target":"http://remote:5984/foo"}' http://localhost:5984/_replicate
In response, futon stats:
W Processed source update #176841152
That part is great.
Last night I did not have immediate access to the shell so I restarted
replication from remote:
curl -X POST -d '{"source":"http://user:p...@public.host:5984/foo";,
"target":"http://remote:5984/foo"}' http://user:p...@pubic.host:5984/_replicate
The response in futon this morning:
W Processed source update #1066
... and it kept sitting there like it was stalled and only continue in smaller
increments.
I restarted CouchDB and restarted from localhost - instant jump to 176 million.
I'm just wondering what might be different accept for that one is against the
public interface, vs. localhost. I'd assume that replication behaves the same
regardless.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-753) Add config option for view compact dir
[
https://issues.apache.org/jira/browse/COUCHDB-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867547#action_12867547
]
Till Klampaeckel commented on COUCHDB-753:
--
I admit, I haven't really thought this through. My issue is that sometimes
people run out of disk space with compaction.
"You" (not necessarily you or CouchDB) could do something like block writes
etc. when a compact is about to replace the database dir. Expose something from
the server via JSON?
> Add config option for view compact dir
> --
>
> Key: COUCHDB-753
> URL: https://issues.apache.org/jira/browse/COUCHDB-753
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
>Reporter: Till Klampaeckel
>
> CouchDB creates a "foo.view.compact" file in the view directory
> ("view_index_dir") when you run compact against a view.
> I'd really like to be able to specify another directory where this ".compact"
> file is created and worked on. This is especially helpful when it's difficult
> to run compaction because you run out of disk space on the same device.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-164) Make error messages more "verbose"
[
https://issues.apache.org/jira/browse/COUCHDB-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863837#action_12863837
]
Till Klampaeckel commented on COUCHDB-164:
--
I got another pretty one:
os_process_error {exit_status,2}
... this means that a path which is somewhere compiled into CouchDB does not
exist anymore. (The viewserver was broken after I moved an install to another
server).
> Make error messages more "verbose"
> --
>
> Key: COUCHDB-164
> URL: https://issues.apache.org/jira/browse/COUCHDB-164
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
>Affects Versions: 0.9
> Environment: Linux till-laptop 2.6.24-21-generic #1 SMP Tue Oct 21
> 23:09:30 UTC 2008 x86_64 GNU/Linux
>Reporter: Till Klampaeckel
>
> The following error designates that there is no space left on device, it
> could say just that. :-)
> [Tue, 18 Nov 2008 18:20:25 GMT] [error] [<0.57.0>] {error_report,
> <0.22.0>,
> {<0.57.0>,
> std_error,
> {mochiweb_socket_server,
> 235,
> {child_error,
> {{{badmatch,{{error,enospc},4414824448}},
>[{couch_stream,write_data,2},
> {couch_stream,write_data,2},
> {couch_stream,handle_call,3},
> {gen_server,handle_msg,6},
> {proc_lib,init_p,5}]},
> {gen_server,
> call,
> [<0.11747.125>,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-756) Credentials from replication are "exposed" in status
Credentials from replication are "exposed" in status
Key: COUCHDB-756
URL: https://issues.apache.org/jira/browse/COUCHDB-756
Project: CouchDB
Issue Type: Improvement
Components: Replication
Reporter: Till Klampaeckel
Priority: Critical
So I started replication with the following command:
curl -X POST http://127.0.0.1/_replicate \
-d '{"source":"http://till:f...@127.0.0.1/bar";,
"target":"http://till:b...@example.org/bar"}'
And now my status window displays:
3467ef: http://till:f...@127.0.0.1/bar/ -> http://till:b...@example.org/bar/
I'd like to see the credentials stripped from display and replaced with XXX or
*** to show that auth was used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-753) Add config option for view compact dir
Add config option for view compact dir
--
Key: COUCHDB-753
URL: https://issues.apache.org/jira/browse/COUCHDB-753
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Reporter: Till Klampaeckel
CouchDB creates a "foo.view.compact" file in the view directory
("view_index_dir") when you run compact against a view.
I'd really like to be able to specify another directory where this ".compact"
file is created and worked on. This is especially helpful when it's difficult
to run compaction because you run out of disk space on the same device.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-41) Differentiate between not existent database and not existant document in response on 404
[
https://issues.apache.org/jira/browse/COUCHDB-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675450#action_12675450
]
Till Klampaeckel commented on COUCHDB-41:
-
I'd like more obvious "error messages":
"Document not found."
"Database does not exist."
> Differentiate between not existent database and not existant document in
> response on 404
>
>
> Key: COUCHDB-41
> URL: https://issues.apache.org/jira/browse/COUCHDB-41
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Environment: CouchDB 0.7.2
>Reporter: Kore Nordmann
>Assignee: Jan Lehnardt
>Priority: Minor
>
> Currently it is not possible to know from a request on a not existent
> document in the database, if the database does not exist, or if it is just
> the document which is missing.
> It would be nice to have this information in the response JSON structure, so
> that the application using the CouchDB could handle such errors more
> gracefully. An extract from a CouchDB interaction showing the problem:
> == Ensure database is absent
> DELETE /test HTTP/1.0
> Host: localhost
> HTTP/1.0 404 Object Not Found
> Server: inets/develop
> Date: Tue, 15 Apr 2008 20:54:20 GMT
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: Tue, 15 Apr 2008 20:54:20 GMT
> Connection: close
> Content-Type: text/plain;charset=utf-8
> {"error":"not_found","reason":"missing"}
> == Try GET on absent database
> GET /test/not_existant HTTP/1.0
> Host: localhost
> HTTP/1.0 404 Object Not Found
> Server: inets/develop
> Date: Tue, 15 Apr 2008 20:54:20 GMT
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: Tue, 15 Apr 2008 20:54:20 GMT
> Connection: close
> Content-Type: text/plain;charset=utf-8
> {"error":"not_found","reason":"missing"}
> == Create database, but not the document
> PUT /test HTTP/1.0
> Host: localhost
> HTTP/1.0 201 Created
> Server: inets/develop
> Date: Tue, 15 Apr 2008 20:54:20 GMT
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: Tue, 15 Apr 2008 20:54:20 GMT
> Connection: close
> Content-Type: text/plain;charset=utf-8
> {"ok":true}
> == Try to fetch document again
> GET /test/not_existant HTTP/1.0
> Host: localhost
> HTTP/1.0 404 Object Not Found
> Server: inets/develop
> Date: Tue, 15 Apr 2008 20:54:20 GMT
> Cache-Control: no-cache
> Pragma: no-cache
> Expires: Tue, 15 Apr 2008 20:54:20 GMT
> Connection: close
> Content-Type: text/plain;charset=utf-8
> {"error":"not_found","reason":"missing"}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
