Re: NEW PREFERENCE - location

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