Subject: NEW PREFERENCE - location

From: Matthew Bishop <[email-masked]>
Date: Sun, 5 May 2019 08:16:02 -0700

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.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 May 2019 10:16:33 +1000

Hi Matthew,

Without commenting on the proposal, the HTTP Preferences registry is Specification Required, which means you need a written specification; that's what the "Reference" item should refer to.

Cheers,

> On 6 May 2019, at 1:16 am, Matthew Bishop <[email-masked]> wrote:
> 
> o  Preference: location
> 
> 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
> o  Notes: This preference is intended to be used with HTTP methods that return a Location
>       This preference supports the Post/Redirect/Get pattern. Wikipedia's entry for this

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrick McManus <[email-masked]>
Date: Mon, 6 May 2019 10:08:59 -0400

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!

---

From: Matthew Bishop <[email-masked]>
Date: Mon, 6 May 2019 12:01:55 -0700

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.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 8 May 2019 19:42:39 -0400

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 <[email-masked]> wrote:

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

---

From: Matthew Bishop <[email-masked]>
Date: Thu, 9 May 2019 17:40:07 -0700

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 <[email-masked]> wrote:

>>> In addition to Mark's advice, can you help the group understand the
>>> scope of this mail?
>>>