Re: [apps-discuss] draft-nottingham-http-problem-04 and content types

Julian Reschke <julian.reschke@gmx.de> Mon, 21 July 2014 17:07 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A67F1A00C3 for <apps-discuss@ietfa.amsl.com>; Mon, 21 Jul 2014 10:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f66ZhY1X3jg for <apps-discuss@ietfa.amsl.com>; Mon, 21 Jul 2014 10:07:08 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0321A0083 for <apps-discuss@ietf.org>; Mon, 21 Jul 2014 10:06:47 -0700 (PDT)
Received: from [31.133.160.134] ([31.133.160.134]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MLOMM-1X9pHH1Thi-000ePu; Mon, 21 Jul 2014 19:06:41 +0200
Message-ID: <53CD48A1.9060104@gmx.de>
Date: Mon, 21 Jul 2014 19:06:41 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Erik Wilde <dret@berkeley.edu>, Daniel Spangler <daniel.spangler@gmail.com>, apps-discuss@ietf.org
References: <CAJQ_3CmNa+O9QR5D8STkS8_NGz7Ck626N5cROegWxpJakKtiAA@mail.gmail.com> <52771A72.8090604@berkeley.edu>
In-Reply-To: <52771A72.8090604@berkeley.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:g85znE5gC+09N18Nycqt8S4dIMt2Jm7kHEABWUeJJpm6jUmMcuV UkbADILu4GqgC3bAMlHaK21kJ2HtdTXrBqe4Teqt8Wkq21bcEPlXG1FCnNzSeiQ3YyiyTac CeDirGps6QPdR2HZe7f51jHZazgnZZcdNUDkxxyo8Ukt0Z20fYuXwDqtMn7fsf7tiBGNFrm ucA7xZNEmI3Zf4CD7HAxQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/lsdF_IPVtllG6zW0U6YJvjTH4Og
Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 and content types
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 17:07:09 -0000

On 2013-11-04 04:54, Erik Wilde wrote:
> ...
> i don't think there's anything special about the HTTP problem types
> here. if a server supports both variants, and a client does not specify
> a preferred variant, or does not distinguish which one it prefers when
> asking for both, then it's up to the server to respond which whatever it
> thinks is the better default choice:
>
> - maybe JSON because on average, people seem to like JSON better these
> days.
>
> - maybe XML, because you can associate it with an XSLT and thus render a
> nice human-readable response in a browser.
>
> it really is up to the server to decide what to do; it could even serve
> XML/XSLT to browser clients, and JSON to non-browser clients. as
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-5.3.2
> puts it:
>
> "A request without any Accept header field implies that the user agent
> will accept any media type in response."
>
> cheers,
>
> dret.
> ...

I'm a bit concerned about the "non-browser clients". Are you suggesting 
to inspect the User Agent header field?

In general, there'll be cases where the request comes from a browser 
(thus UA sniffing doesn't help), the preferred result is text/html on 
success (XHR code getting HTML fragments), but the preferred result for 
failure cases would be JSON.

Maybe another case for "Prefer:"?

Best regards, Julian