Re: NEW PREFERENCE - location

[Matthew Bishop <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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.
>>
>