Subject: Re: [scim] http://tools.ietf.org/html/draft-ietf-scim-api-02#section-3.12: "X-HTTP-Method-Override"

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Feb 2014 13:26:07 -0800

This is a common REST practice. We probably need to have a reference for this item.

As to whether it is needed, it would be interesting to know if anyone in the group is worried about firewalls limiting use of PATCH and DELETE, etc.

Phil

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

On 2014-01-22, at 2:46 AM, Julian Reschke <[email-masked]> wrote:

> Hi there.
> 
> I think it's problematic for a standards-track document to allow use of a header field that is not in the HTTP header field registry.
> 
> If you really believe that is is needed (which I doubt) than you really ought to work on a separate spec that defines and registers it in the header field registry.
> 
> Best regards, Julian
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Feb 2014 22:36:41 +0100

> This is a common REST practice. We probably need to have a reference for this item.

Define "common REST practice".

> As to whether it is needed, it would be interesting to know if anyone in the group is worried about firewalls limiting use of PATCH and DELETE, etc.

a) I assume most write operations go over https anyway, so this is not a 
concern.

b) *If* a firewall blocks certain HTTP methods then we should respect 
that. It's a feature of the protocol that inspecting the method name 
allows making policy decisions. If you believe a firewall does it out of 
incompetence, get the firewall fixed.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Feb 2014 13:49:20 -0800

Phil

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

> Define "common REST practice".

I've seen this in books and on the web. I don't have any particular references right now…that's my point, we need one.
> a) I assume most write operations go over https anyway, so this is not a concern.

This isn't an HTTPS vs HTTP issue AFAIK (though SCIM communication should always be on HTTPS).  It is a firewall policy issue.  This could happen in some mobile gateways as well.  Though I am not sure how it would impact a client using SCIM.  I just know these limitations are out there in the real world.
> 
> b) *If* a firewall blocks certain HTTP methods then we should respect that. It's a feature of the protocol that inspecting the method name allows making policy decisions. If you believe a firewall does it out of incompetence, get the firewall fixed.
> 
> Best regards, Julian
I wouldn't say the firewalls (or proxies) are broken. Just overly and unnecessarily conservatively configured.

Never-the-less, my point is to ask the WG does anyone need HTTP method override?

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Feb 2014 22:59:18 +0100

> This isn't an HTTPS vs HTTP issue AFAIK (though SCIM communication should always be on HTTPS).  It is a firewall policy issue.  This could happen in some mobile gateways as well.  Though I am not s…

If it's HTTPS then the firewall can only intercept by breaking up TLS. 
In which case you probably have bigger problems :-)

So please collect evidence before doing something that is outside our 
(IETF) specs.

> ...

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Feb 2014 14:43:33 -0800

What about Proxies? Gateways?  Limited client libraries?

It is incredibly common practice. I did a search for HTTP Method Override and got 1000s of hits.  But I couldn't find citable reference. It is something that Google, Microsoft, and many many others (including Jersey) have been supporting for some time.  It seems to be accepted common practice that has not been formally standardized.

I agree with you, but I just want to confirm, since it was in the spec from SCIM 1, why Sec 3.12 (API) might be still needed.  Does anyone know?

Phil

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

On 2014-02-18, at 1:59 PM, Julian Reschke <[email-masked]> wrote:

> If it's HTTPS then the firewall can only intercept by breaking up TLS. In which case you probably have bigger problems :-)
> 
> So please collect evidence before doing something that is outside our (IETF) specs.
> 
>> ...
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Feb 2014 23:57:28 +0100

> What about Proxies? Gateways?  Limited client libraries?

Maybe. Do you have something concrete? For instance, svn has been using 
DLETE, PUT and WebDAV methods for almost a decade now, without any 
overrides (as far as I can tell).

> I agree with you, but I just want to confirm, since it was in the spec from SCIM 1, why Sec 3.12 (API) might be still needed.  Does anyone know?

Yes. Please think about it and check.

Either it's needed (in which case it needs a proper spec), or it's not.

Best regards, Julian

---

From: Phil Hunt <[email-masked]>
Date: Tue, 18 Feb 2014 16:07:19 -0800

I have added a ticket:
http://trac.tools.ietf.org/wg/scim/trac/ticket/65

Comments appreciated (either here on this thread), or directly on the ticket.  Especially from anyone who thinks we need to keep it.

Phil

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

On 2014-02-18, at 2:57 PM, Julian Reschke <[email-masked]> wrote:

> Maybe. Do you have something concrete? For instance, svn has been using DLETE, PUT and WebDAV methods for almost a decade now, without any overrides (as far as I can tell).
>