Subject: Fwd: New Version Notification for draft-hunt-http-rest-redirect-00.txt

From: Phil Hunt <[email-masked]>
Date: Wed, 15 Jan 2014 16:03:41 -0800

In the SCIM working group, the issue came up as to what to do about HTTP Redirects for RESTful services (of which SCIM is one). On Leif's suggestion, I put together a quick draft covering the topic to raise to the HTTPbis working group as this seems to apply to all RESTful services.

I also note that there is an existing draft http://datatracker.ietf.org/doc/draft-reschke-http-status-308/, which I have referenced in this draft.

Phil

@independentid
www.independentid.com
[email-masked]

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-hunt-http-rest-redirect-00.txt
> Date: 15 January, 2014 3:52:44 PM PST
> To: Phil Hunt <[email-masked]>, "Phil Hunt" <[email-masked]>
> 
> 
> A new version of I-D, draft-hunt-http-rest-redirect-00.txt
> has been successfully submitted by Phil Hunt and posted to the
> IETF repository.
> 
> Name:		draft-hunt-http-rest-redirect
> Revision:	00
> Title:		HTTP Redirect Codes for RESTful Services
> Document date:	2014-01-16
> Group:		Individual Submission
> Pages:		5
> URL:            http://www.ietf.org/internet-drafts/draft-hunt-http-rest-redirect-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hunt-http-rest-redirect/
> Htmlized:       http://tools.ietf.org/html/draft-hunt-http-rest-redirect-00
> 
> 
> Abstract:
>   This specification clarifies the use of HTTP redirect codes when used
>   with RESTful services.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 10:10:32 +0100

On 2014-01-16 01:03, Phil Hunt wrote:
> In the SCIM working group, the issue came up as to what to do about HTTP
> Redirects for RESTful services (of which SCIM is one). On Leif's
> suggestion, I put together a quick draft covering the topic to raise to
> the HTTPbis working group as this seems to apply to all RESTful services.
>
> I also note that there is an existing draft
> http://datatracker.ietf.org/doc/draft-reschke-http-status-308/, which I
> have referenced in this draft.
>
> Phil
> ...

-1

a) You reference an outdated spec.

b) You have statements about the existing redirection codes that are in 
conflict with the relevant specs.

What problem are you trying to solve here?

Best regards, Julian

---

From: Mark Baker <[email-masked]>
Date: Thu, 16 Jan 2014 10:21:55 -0500

>> have referenced in this draft.

+1 to your -1

> conflict with the relevant specs.

c) you specify a protocol that is known to be incompatible with
deployed implementations and inconsistent with REST and Web
architecture in significant ways

> What problem are you trying to solve here?

News to me, but SCIM is apparently an IETF WG;

https://datatracker.ietf.org/wg/scim/charter/

IMO, this draft doesn't bode well for the ability of the group to meet
its (REST-oriented) charter, or for implementations to be deployed
while interoperating properly with existing Web infrastructure.

Mark.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 07:42:56 -0800

Assuming you are refering to the 308 redirect draft. What is the current reference for 308?

REST services need redirects that do not convert to GET. That would corrupt the operation. 

Phil

> On Jan 16, 2014, at 7:21, Mark Baker <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 16:50:15 +0100

> Assuming you are refering to the 308 redirect draft. What is the current reference for 308?

No, I'm referring to citing RFC 2616.

> REST services need redirects that do not convert to GET. That would corrupt the operation.

Yes. For some value of "Rest services"; I'd recommend to avoid that term 
altogether; just define an HTTP based service that makes sense and uses 
HTTP properly.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 08:00:17 -0800

Thanks.  2616 should be changed. 

I am open to broadening applicability to all non-browser HTTP services. 

Phil

> On Jan 16, 2014, at 7:50, Julian Reschke <[email-masked]> wrote:
> 
> Yes. For some value of "Rest services"; I'd recommend to avoid that term altogether; just define an HTTP based service that makes sense and uses HTTP properly.
> 
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 17:03:00 +0100

> Thanks.  2616 should be changed.

The point being that the definitions of the redirect codes have been 
rewritten a lot in HTTPbis.

Optimally, there is no need to have an additional document *at all*.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 08:15:04 -0800

Thanks. I believe http://tools.ietf.org/search/draft-ietf-httpbis-p2-semantics-25 does cover the issue. 

Though

Phil

> On Jan 16, 2014, at 8:03, Julian Reschke <[email-masked]> wrote:
> 
> The point being that the definitions of the redirect codes have been rewritten a lot in HTTPbis.
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 11:09:41 -0800

Sorry for this, I keep re-reading the httpbis semantics draft, and I must confess, the redirect definitions for 301,302, 307 seem unclear.
>       Note: For historic reasons, a user agent MAY change the request
>       method from POST to GET for the subsequent request.  If this
>       behavior is undesired, the 307 (Temporary Redirect) status code
>       can be used instead.

For example, both 301 and 302 essentially allow a client to behave any way it wants.  302, which is essentially a temporary redirect can work either way. Yet, there is 307 which forbids alteration of the HTTP request.

From the server perspective, it is confusing as to whether 307 or 302 should be used.  From a client perspective, it is unclear what the client must do when 301 or 302 is used.

Even more confusing is that both 301 and 302 say 307 can be used.  Which means now the server cannot indicate whether the redirect is permanent or not.

Why not keep it simple and have 307 and 308 mimic 302 and 301 except with no HTTP request changes being allowed?  The decision tree is much cleaner and the behaviour is cleanly separated.

Apologies if you have already had a long debate on this.

Phil

@independentid
www.independentid.com
[email-masked]

On 2014-01-16, at 8:15 AM, Phil Hunt <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Mark Baker <[email-masked]>
Date: Thu, 16 Jan 2014 14:13:38 -0500

> REST services need redirects that do not convert to GET. That would corrupt the operation.

None of the redirection codes "convert to GET". What, for example, a
303 response means is that the server is attempting to provide
additional information to the client via another resource. A REST
service would understand this and so know not to try to send another
message with the same meaning as the initial one. It may or may not
choose to send a GET request to that new URI, and if not, would
probably signal this as an error condition.

Mark.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 20:31:40 +0100

> For example, both 301 and 302 essentially allow a client to behave any way it wants.  302, which is essentially a temporary redirect can work either way. Yet, there is 307 which forbids alteration…

Not "any way". They can rewrite POST to GET. That's it.

>  From the server perspective, it is confusing as to whether 307 or 302 should be used.  From a client perspective, it is unclear what the client must do when 301 or 302 is used.

How is it unclear?

> Even more confusing is that both 301 and 302 say 307 can be used.  Which means now the server cannot indicate whether the redirect is permanent or not.

Because 308 is a new, experimental status code.

"Note: This status code is similar to 302 (Found), except that it does 
not allow changing the request method from POST to GET. This 
specification defines no equivalent counterpart for 301 (Moved 
Permanently) ([status-308], however, defines the status code 308 
(Permanent Redirect) for this purpose)."

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 12:11:17 -0800

Both 301 and 302 say to use 307 if conversion to GET is not desired.  

With 307 used for both temporary and perm redirect, 307 loses meaning causing the confusion.

Phil

@independentid
www.independentid.com
[email-masked]

> "Note: This status code is similar to 302 (Found), except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 (Moved Permanently) ([status-308], however, defines the status code 308 (Permanent Redirect) for this purpose)."

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 21:23:26 +0100

> With 307 used for both temporary and perm redirect, 307 loses meaning causing the confusion.

Do you have a concrete change proposal that doesn't require putting 308 
into the base spec?

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 12:43:06 -0800

What is the objection to 308?  

If there is good reason not to use it, why not pick another code?

Phil

@independentid
www.independentid.com
[email-masked]

On 2014-01-16, at 12:23 PM, Julian Reschke <[email-masked]> wrote:

> Do you have a concrete change proposal that doesn't require putting 308 into the base spec?
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 21:48:08 +0100

> What is the objection to 308?

It's new. We can't put it into RFC2616bis due to our charter.

> If there is good reason not to use it, why not pick another code?

The spec is already approved and the status code is registered.

That being said, Chrome hasn't made any progress implementing it because 
it conflicts with an internal use of 308 in the Google Drive HTTP binding.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 Jan 2014 12:56:40 -0800

The feeling in the SCIM WG, was that we should escalate to the HTTPbis group rather than try to tackle it. I definitely hear you about the charter and the Chrome issue.

Still, from my perspective, the existing semantics draft is not clear with regards to both 301 and 302 suggesting the same 307 code.

Sounds like, I should leave my proposal as is, except maybe to change 308 to 309 and let the ADs sort it out. I can also make sure it doesn't conflict with the semantics draft (the above issue aside). 

One of the reasons I chose REST in my draft was to narrow the scope of services to avoid any overlap with user-agent.  Does that occur if I open it to any HTTP service not intended for user-agents?

Happy to make any other changes to the draft in the mean time to reflect the discussion.

Thanks,

Phil

@independentid
www.independentid.com
[email-masked]

On 2014-01-16, at 12:48 PM, Julian Reschke <[email-masked]> wrote:

> That being said, Chrome hasn't made any progress implementing it because it conflicts with an internal use of 308 in the Google Drive HTTP binding.
> 
> Best regards, Julian
> 
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jan 2014 22:12:18 +0100

> The feeling in the SCIM WG, was that we should escalate to the HTTPbis group rather than try to tackle it. I definitely hear you about the charter and the Chrome issue.

Well, feedback from the Chrome team back in 2012 was to go ahead and use 
308. They "just" need to do their homework now.

> Still, from my perspective, the existing semantics draft is not clear with regards to both 301 and 302 suggesting the same 307 code.

Again: can you propose something else that works within the constraints 
we're working in?

> Sounds like, I should leave my proposal as is, except maybe to change 308 to 309 and let the ADs sort it out. I can also make sure it doesn't conflict with the semantics draft (the above issue asid…

What? Do you want to seriously suggest an alias of 308? That's not going 
to fly.

> One of the reasons I chose REST in my draft was to narrow the scope of services to avoid any overlap with user-agent.  Does that occur if I open it to any HTTP service not intended for user-agents?

"We use the term "user agent" to refer to any of the various client 
programs that initiate a request, including (but not limited to) 
browsers, spiders (web-based robots), command-line tools, native 
applications, and mobile apps." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-25.html#rfc.section.2.1.p.2>

...so I'm not sure what the question is about. In general, thinking of 
"Rest services" as something different from what's used by a browser is 
a really bad idea.

Best regards, Julian