[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190307#comment-13190307 ] Jason Smith commented on COUCHDB-1304: -- Good points, Jan and Benoit. You make a good case for the 1%. I hope Couch has a compelling story for writing blog software, not bank software: the easy things easy, the hard things possible. That's just IMHO. Either default is fine. > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: bigcouch sharding uestion
On Thu, Jan 19, 2012 at 19:41, kzhang wrote: > Hi, > > If I have three nodes to set up a cluster, what difference does it make if > 1) I set up three shards, with each of the three nodes being the primary of > one shard, with replication running among them, so if one node goes down, > the other two can fully take over; v.s. 2) if still the same three nodes, I > set up six shards, still running replication among them. > > I know it sounds more overhead in 2). But is there any performance gain/loss > associated with either approach? The overhead should be minimal, especially with BigCouch, since it's limited to the connection and request overhead. With BIgCouch, the requests between servers are not HTTP, so there's no HTTP overhead and I would bet the connections are persistent, so there isn't any added overhead there. The extra overhead is additional resources for the additional connections between servers, but that's negligible, and making the individual shards' responses smaller might actually mean memory usage is more stable since the JSON is split into more manageable chunks for the serializer. In general, over-sharding is a great tool and will make your life a lot easier when you decide you need more than 3 nodes. Someone from Cloudant can chime in if I'm wrong, but I wouldn't hesitate to set up 10x or 20x that many shards, depending on how quickly you expect to scale out. As an added bonus it will increase parallelism in your view index generation. -Randall > > I guess I am not sure what is the standard/ideal config for No. of shards/ > No. of Nodes. > > -- > View this message in context: > http://couchdb-development.1959287.n2.nabble.com/bigcouch-sharding-uestion-tp7206277p7206277.html > Sent from the CouchDB Development mailing list archive at Nabble.com.
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189875#comment-13189875 ] Benoit Chesneau commented on COUCHDB-1304: -- i'm against enabling it by defaut. For the security it's better to have a limited session (like bank indeed). couchdb is still a database afterall. > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189773#comment-13189773 ] Robert Newson commented on COUCHDB-1304: Let's keep it disabled by default then, it's an easy thing to switch on. A further question of whether the toggle should be finer-grained than per-server has been raised by Randall. I think it's a good question but should be on a new ticket if we intend to pursue it. > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
On 20 January 2012 13:12, Robert Newson (Commented) (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189753#comment-13189753 > ] > > Robert Newson commented on COUCHDB-1304: > > > Enabling by default works for me, can I get some votes? +1.
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189771#comment-13189771 ] Jan Lehnardt commented on COUCHDB-1304: --- I'm against enabling this as the default. Strictly speaking it is an API change, but I could be persuaded to look the other way. I don't like the idea of shipping a default setting that leaves a session open beyond a browser's lifetime. For me this is gmail vs. online backing. the former allows persistent cookies and the other doesn't. Both have their merits in their respective situations. I'm just more comfortable being the bank by default. > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189753#comment-13189753 ] Robert Newson commented on COUCHDB-1304: Enabling by default works for me, can I get some votes? > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1304) set Expires header on session cookies to make them persistent
[ https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson resolved COUCHDB-1304. Resolution: Fixed Fix Version/s: (was: 1.3) 1.2 Feature applied to 1.2.x and master. > set Expires header on session cookies to make them persistent > - > > Key: COUCHDB-1304 > URL: https://issues.apache.org/jira/browse/COUCHDB-1304 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 1.1 >Reporter: max ogden >Assignee: Robert Newson >Priority: Minor > Labels: authentication, cookie > Fix For: 1.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > currently couch's cookie based authentication only sets session cookies as > opposed to persistent cookies. the difference between these two is the > Expires header. if it is not present most web browsers will delete your > cookie when you quit your browser, whereas if it is set then your browser > keeps the cookie around until the time specified by the Expires header. > This sucks for UX because users quit and re-launch their browser they'll have > to log in again. > I am proposing that we set the Expires header in cookies to match the time in > the couch_httpd_auth timeout > p.s. this is similar to the issue I opened > https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't > realize that what I really wanted was the Expires header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
bigcouch sharding uestion
Hi, If I have three nodes to set up a cluster, what difference does it make if 1) I set up three shards, with each of the three nodes being the primary of one shard, with replication running among them, so if one node goes down, the other two can fully take over; v.s. 2) if still the same three nodes, I set up six shards, still running replication among them. I know it sounds more overhead in 2). But is there any performance gain/loss associated with either approach? I guess I am not sure what is the standard/ideal config for No. of shards/ No. of Nodes. -- View this message in context: http://couchdb-development.1959287.n2.nabble.com/bigcouch-sharding-uestion-tp7206277p7206277.html Sent from the CouchDB Development mailing list archive at Nabble.com.