Re: [jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses

2011-06-20 Thread Benoit Chesneau
On Mon, Jun 20, 2011 at 12:19 PM, Robert Newson (JIRA) j...@apache.org wrote:

    [ 
 https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051903#comment-13051903
  ]

 Robert Newson commented on COUCHDB-1175:
 

 I think IE8 still sends;

 Accept: image/jpeg, application/x-ms-application, image/gif, 
 application/xaml+xml, image/pjpeg, application/x-ms-xbap, 
 application/x-shockwave-flash, application/msword, */*

 http://www.gethifi.com/blog/browser-rest-http-accept-headers


 Improve content type negotiation for couchdb JSON responses
 ---

                 Key: COUCHDB-1175
                 URL: https://issues.apache.org/jira/browse/COUCHDB-1175
             Project: CouchDB
          Issue Type: Improvement
    Affects Versions: 1.0.2
            Reporter: Robert Newson
            Assignee: Robert Newson
            Priority: Blocker
             Fix For: 1.1.1, 1.2


 Currently we ignore qvalues when negotiation between 'application/json' and 
 'text/plain' when returning JSON responses.
 Specifically, we test directly for 'application/json' or 'text/plain' in the 
 Accept header. Different branches have different bugs, though. Trunk returns 
 'application/json' if 'application/json' is present at all, even if it's 
 less preferred than 'text/plain' when qvalues are accounted for.
 We should follow the standard.

 --
 This message is automatically generated by JIRA.
 For more information on JIRA, see: http://www.atlassian.com/software/jira




status update:
I'm still on my API list blah. Hopefully I will finished it until
tomorrow, in the mean time we can use as a start the api doc done by
couchbase.

- benoit


Re: [jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses

2011-06-18 Thread Benoit Chesneau
On Sat, Jun 18, 2011 at 10:52 AM, Marcello Nuccio (JIRA)
j...@apache.org wrote:

    [ 
 https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051477#comment-13051477
  ]

 Marcello Nuccio commented on COUCHDB-1175:
 --

 https://github.com/couchapp/couchdb-login-jquery does not work with password 
 protected DBs, because the browser cannot download the couchapp.

 How can I get any Javascript run on the browser if I cannot get it first?

 authentication_redirect solves this specific use-case.

 Improve content type negotiation for couchdb JSON responses

Again you don't need the redirect. Change the header in settings,
catch the error, pass the the base64 encoded username password to auth
header and you're done.

- benoit


Re: [jira] [Commented] (COUCHDB-1175) Improve content type negotiation for couchdb JSON responses

2011-06-18 Thread Benoit Chesneau
On Sat, Jun 18, 2011 at 11:22 AM, Johannes J. Schmidt (JIRA)
j...@apache.org wrote:

    [ 
 https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051482#comment-13051482
  ]

 Johannes J. Schmidt commented on COUCHDB-1175:
 --

 Hey come on, this is a very relevant bug. For me its a blocker to use 1.0.2 
 until this is fixed.

 My scenario:
 I have a CouchApp and give my users their own dbs, which they can secure if 
 they want to.
 Behind a vhost I route example.com/myfairuser to a list function inside the 
 db myfairuser.
 Now imagine myfairuser is secured. How can you login there?
 Don't tell me the user has to return to example.com after reading the nice 
 {error:unauthorized,reason:You are not authorized to access this db.} 
 using the browser navigation.

Not sure to understand here?


If header is not WWW-Authenticateb but something else, ajax will be
abble to catch it as an error, then on error callback you can redirect
user to another page, or just letting him to pass username/password.
That is solving this issue while the status error is still 401 which
is expected by other clients.

- benoît