Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CA1438113 for ; Tue, 16 Aug 2011 14:30:49 +0000 (UTC) Received: (qmail 97745 invoked by uid 500); 16 Aug 2011 14:30:48 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 97688 invoked by uid 500); 16 Aug 2011 14:30:47 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 97680 invoked by uid 99); 16 Aug 2011 14:30:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Aug 2011 14:30:46 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of marcello.nuccio@gmail.com designates 209.85.213.180 as permitted sender) Received: from [209.85.213.180] (HELO mail-yx0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Aug 2011 14:30:39 +0000 Received: by yxi11 with SMTP id 11so5545421yxi.11 for ; Tue, 16 Aug 2011 07:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zJa2vPoL3qctbIudwWPaVERY4ZiFU9X4EzBB2F9CC5U=; b=fQkjSB9GyF9KD6PwH1RIUfd/7IY+1gJBPhKSIuyJ6Nr6N8A4jC47oz1QxyNAKcZ4E6 crZVecC0USYOod0oPUyVvffrHZtQjv91GwW3MFraOZNkvGFxmwrxTN9om8FKIM8Rkmor wLvaa7gW3s549qw3LkcPe97ANRDR0wfQV44JY= MIME-Version: 1.0 Received: by 10.42.145.196 with SMTP id g4mr5430358icv.151.1313505018116; Tue, 16 Aug 2011 07:30:18 -0700 (PDT) Received: by 10.42.245.1 with HTTP; Tue, 16 Aug 2011 07:30:18 -0700 (PDT) In-Reply-To: References: <4E371B93.8060303@kearns.net.au> Date: Tue, 16 Aug 2011 16:30:18 +0200 Message-ID: Subject: Re: to CouchApp or not to CouchApp From: Marcello Nuccio To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 2011/8/16 Benoit Chesneau : > On Tuesday, August 16, 2011, Marcello Nuccio > wrote: >> 2011/8/16 Benoit Chesneau : >>> On Tue, Aug 16, 2011 at 1:01 PM, Robert Newson > wrote: >>> >>>> My revised proposal was to send text/html (and 302's) in all cases >>>> except for the very specific case where the Accept header is exactly >>>> one item and that item is 'application/json'. All programmatic calls >>>> can meet that (libraries incapable of this are de facto poor >>>> libraries), and the ambiguity is vanquished. >>> >>> >>> should be application/json imo. We are a document oriented db speaking >>> in json first. If someone accept text/html where the only thing we >>> send on resource is json, we should send an error by default (maybe a >>> setting could override that). >> >> This is not what is needed to fix the bug. >> The only requirement is: if I ask an HTML, give me an HTML, not a JSON. >> > > that's not how the spec works. Sorry, I said it wrong. What I wanted to say is: if I request a resource with a mime-type of "text/html", I expect the response to be "text/html", if the Accept header says "text/html" is an acceptable format. In this case the value of "q" is not relevant because we only have the resource in HTML format. You can do a little test: $ curl -o/dev/null -D- -H 'Accept: image/jpeg,image/png;q=0.1' http://couchdb.apache.org/img/sketch.png HTTP/1.1 200 OK [...] Content-Type: image/png Since sketch.png is available only as "image/png", Apache responds with "image/png" even if "image/jpeg" is preferred according to the Accept header. >> This is what I do if the user is authenticated, and I see no reason >> for not doing it when the response is a 401. > > i don't follow. how it is related? I ask to apply the same logic whatever the status code of the response. If when the response is "200 OK" the content-type is "text/html", then why not respond with the same content-type for a "401 Unauthorized" response? Obviously the content will be different (an html login form for the 401). Marcello