Re: NEW PREFERENCE - location

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.
>>>>
>>>