Closed danielquinn closed 8 years ago
I agree HTTPS reduces the risk of intermediaries blocking verbs, so am OK with that.
However PATCH is ill-defined, and lacks interoperability, even though Rails may happen to use it.
I don't know much about Rails, but Python/Django with Django Rest Framework supports patch transparently, so I assumed that this was common practise.
I guess the question is: whether it's well-defined or not, if all that's required is that the client send the right Method:
header and a defined-by-us format for the body, then what's the harm in using it? I've seen PATCH work just fine in modern browsers, so I figured that that was sufficient, but like I said I'm not married to this idea, so if you'd prefer we keep the discouragement about PATCH, then I can fix my PR.
I'd prefer to not mention PATCH, it might work point-to-point (as would any verb you cared to make up) but it's still highly contentious in standards land.
Alright, PATCH reference restored :-)
Um, recent real-world experience.
F5 WAF blocks verbs other than GET
/ POST
, so people use X-HTTP-Method-Override
. 🙈
Wow, really? Well if a firewall is blocking PUT and DELETE requests for security reasons, I'd consider that broken by design, but I guess if we're using these sorts of tools, (why?) then yeah, this PR is void.
As firewalls (typically) operate at layer 3 and HTTP method values are at layer 5 (I think I've got those numbers right) there's very few circumstances where a firewall would filter these sorts of requests. What's more, this should be impossible because we're using HTTPS everywhere... right?
I also removed the bit about PATCH because this behaviour leads to overloading PUT. PUT == full updates, PATCH == partial ones. I'm not fussed on this one as much as I am about the other bit though.