Re: NEW PREFERENCE - location
Matthew Bishop <matt@thebishops.org> Fri, 10 May 2019 00:45 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1415120091 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2019 17:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thebishops-org.20150623.gappssmtp.com
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 Cby9E2xnNTcL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2019 17:45:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8815A120045 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2019 17:45:33 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hOtaj-0007ox-0J for ietf-http-wg-dist@listhub.w3.org; Fri, 10 May 2019 00:40:49 +0000
Resent-Date: Fri, 10 May 2019 00:40:49 +0000
Resent-Message-Id: <E1hOtaj-0007ox-0J@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <matt@thebishops.org>) id 1hOtaf-0007oB-BM for ietf-http-wg@listhub.w3.org; Fri, 10 May 2019 00:40:45 +0000
Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <matt@thebishops.org>) id 1hOtaa-0005pw-K8 for ietf-http-wg@w3.org; Fri, 10 May 2019 00:40:44 +0000
Received: by mail-lf1-x12c.google.com with SMTP id d8so2867628lfb.8 for <ietf-http-wg@w3.org>; Thu, 09 May 2019 17:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thebishops-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jw5dveMpo7CCdzHai7z8Iem8Ai6eBXvB9Qpw1Wmcpao=; b=xoo456aKpzRv9CKJJPxycNC55MJlqkEsu6G76znJRiYVH0uR1oYmIji5f0A55JvJea /jC+3T0jXgwayhsVnZMYOVzXxsU4gREG1ma9wQts8TixiZnEF96+EWDjqozrH/q4Ev68 cmIRX2naxlzO3JHBx1Sc4s2TlPKzLCZldnZEdwaHLt5Gva3ojhG113loRlcRP2wMdJSn Si4Q/aJfL4KEtKdg/A4XjN+5cOo7s3pi7tisNM5Emc0WwO0PIL/ivnT+jspgQY7IDcdR Utrg+i3fagZ4qV0kGDjngOwH++nnXFV09jXNxKPNeiTOKrOp/+yVn4FaW3zyEDCssN5v IAxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jw5dveMpo7CCdzHai7z8Iem8Ai6eBXvB9Qpw1Wmcpao=; b=VkvCcndQi7axsf9fxr8Yy9YjTV9257hmsJmbTw4vpdbg+jiiEFIqM4JXIW90HLEdyf 4/WVgZW/yOJmlY7udCdeKSi3jj/0cgueOmO4C18U9liaYEoeyzJ/ns6jqi5FaxfPDU9G LGKPi4TvlMRxnqlr6nWwQgYlJ7AbWD9z4eCe8wOGThvRA0BdDwVMKXs8/fY2a3n4VxzW 9VEidKnYSIMUH+dTX+nceyN84Vz2eLLeB83fiKybaxwbiuQYan4sRi5mYuLKI0Bfg5o+ OZ3TbR7qLCThp71EWNMcw+yxjFdF/iPznfbQZ3Exn/pKrycMQWnE+QfoWwJgmGqx05GC YmBg==
X-Gm-Message-State: APjAAAWURLBMlVBivqKp2qMtCxxmZlC/0mhwLdtZp24JAMwdgeAVBPK1 8JIAo12Vy0//FUdQTJjS7IFsJ7Oi5nSwSUYcTNfULxdthoY=
X-Google-Smtp-Source: APXvYqwFAJKJkruvpXATKbXIUd3KMt5eXYi2yAW3+gKsXWYop7X/VNePaNRtHTv04r+zfoQGkxu3UgRfLWCsMK8YQwU=
X-Received: by 2002:ac2:5606:: with SMTP id v6mr3734510lfd.129.1557448818792; Thu, 09 May 2019 17:40:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAEvuJbZN9abyEQTnnHEi9vnPXhdCTSQbvz7_MORgn+6H6gd7Sg@mail.gmail.com> <CAOdDvNrotbuXOMRr-eM0cUWYYiKrk0409rX1vE9OXg+ZVfGtMw@mail.gmail.com> <CAEvuJbYrx+rGNG1C8zJaOgFJaFyoAQeJqiqHXQvRJHhgz3uQbQ@mail.gmail.com> <CAOdDvNov8Qpw56ff=wJnVatOYPiwKDgaG-dgy8bT4mwGd=fY5A@mail.gmail.com>
In-Reply-To: <CAOdDvNov8Qpw56ff=wJnVatOYPiwKDgaG-dgy8bT4mwGd=fY5A@mail.gmail.com>
From: Matthew Bishop <matt@thebishops.org>
Date: Thu, 09 May 2019 17:40:07 -0700
Message-ID: <CAEvuJbam8WsFJbGOqAu+EPpwn_=wbUA+ffANeQRm_gn2aBq9wQ@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000099b25905887dcf89"
Received-SPF: none client-ip=2a00:1450:4864:20::12c; envelope-from=matt@thebishops.org; helo=mail-lf1-x12c.google.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hOtaa-0005pw-K8 8141b4f8866efbc7f347bc38a241c13f
X-Original-To: ietf-http-wg@w3.org
Subject: Re: NEW PREFERENCE - location
Archived-At: <https://www.w3.org/mid/CAEvuJbam8WsFJbGOqAu+EPpwn_=wbUA+ffANeQRm_gn2aBq9wQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36627
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
When I looked at the other preferences, like `return`, I find they often have flags for the opposite behaviour. `return` has both `minimal` and `representation` to let clients control the response body of a given API. `location=stay` lets the client state that an API that normally returns a redirect response should instead return the Location and a 2xx status. It is the opposite behaviour to `redirect` and thus gives the client explicit control of their response. On Wed, May 8, 2019 at 4:42 PM Patrick McManus <mcmanus@ducksong.com> wrote: > Hi Matthew, thanks for the replies. > > I think it might be helpful to drill down on when a client would want to > offer "stay". You make a compelling case for "redirect" - but is this > really a preference or is it some way of saying you wish the server were > doing something better right now? > > You certainly don't need an implementation to write a draft; but the need > for interoperability between implementations is something the group > considers when deciding whether one should proceed. There are no strict > rules about it - but experience is always welcomed. > > -Patrick > > > > > On Mon, May 6, 2019 at 3:02 PM Matthew Bishop <matt@thebishops.org> wrote: > >> Mark, I misunderstood the submission policy at >> https://tools.ietf.org/html/rfc7240#section-5.1 to mean a specification >> had to be referenced. I see now that a specification has to be submitted >> with the completed preference template therein. I will write up a >> specification submission for this preference. >> >> Patrick, this preference is based on experience and common best practices >> for handling POST requests from the client. An API that accepts POSTs will >> usually return a 201 Created with a Location, but I have found that clients >> actually want to specify that a 303 See Other is returned so their client >> can redirect to the Location URL and save them the coding process of >> directly fetching the Location resource in client code. >> >> This preference is similar to the "return=representation" preference >> except that the client wants an actual redirect to occur to run the second >> fetch through the caching mechanisms. The resource at Location may already >> be cached. >> >> Does an exact implementation need to exist first? I was thinking of using >> the preference beforehand but thought that was not appropriate. >> >> On Mon, May 6, 2019 at 7:09 AM Patrick McManus <mcmanus@ducksong.com> >> wrote: >> >>> Hello Matt, >>> >>> In addition to Mark's advice, can you help the group understand the >>> scope of this mail? >>> >>> Is it proposed based on experience or an idea? Are there interoperable >>> implementations yet? In what instance would you expect stay to be used? >>> Why would this be a client side preference? >>> >>> Thanks! >>> >>> >>> On Sun, May 5, 2019 at 11:19 AM Matthew Bishop <matt@thebishops.org> >>> wrote: >>> >>>> o Preference: location >>>> >>>> o Value: One of either "redirect" or "stay" >>>> >>>> o Description: In state change requests, the client prefers the server >>>> to return either a >>>> redirect status code or a 2xx status code when a response >>>> contains a Location >>>> header. The value "redirect" indicates a 303 See Other should be >>>> returned. The value >>>> "stay" indicates an appropriate 2xx status should be returned. >>>> >>>> o Reference: HTTP/1.1: Semantics and Content, section 4.4.4 303 See >>>> Other >>>> [https://tools.ietf.org/html/rfc7231#section-6.4.4] >>>> >>>> o Notes: This preference is intended to be used with HTTP methods that >>>> return a Location >>>> header and either a 303 or a 2xx status code. >>>> >>>> This preference supports the Post/Redirect/Get pattern. >>>> Wikipedia's entry for this >>>> pattern explains it's value in client interactions. See >>>> https://en.wikipedia.org/wiki/Post/Redirect/Get for details. >>>> >>>
- NEW PREFERENCE - location Matthew Bishop
- Re: NEW PREFERENCE - location Mark Nottingham
- Re: NEW PREFERENCE - location Patrick McManus
- Re: NEW PREFERENCE - location Matthew Bishop
- Re: NEW PREFERENCE - location Patrick McManus
- Re: NEW PREFERENCE - location Matthew Bishop