W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2019

Re: NEW PREFERENCE - location

From: Matthew Bishop <matt@thebishops.org>
Date: Thu, 9 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>
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.
Received on Friday, 10 May 2019 00:40:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC