3

Suppose my server exposes an HTTP-based API that uses the PATCH method introduced by RFC 5789. Is it possible that clients (browsers or otherwise) behind corporate firewalls, proxies, caches, parental controls filters and the like will encounter any problems using this method? If so, how likely is this?

Given that PATCH was not part of the original HTTP specs, but introduced later on, I could imagine that some programs will simply reject such requests because of the "invalid" method. On the other hand, I hope that such software simply passes through everything and at most apply some restrictions to certain HTTP methods such as POST (e.g. not caching its results).

Note that I do not ask about PATCH support on the server side or within the browser, but only about components between client and server that I neither know nor control. Also, the question whether or not PATCH in itself is a good idea for APIs is out of scope for this question.

Community
  • 1
  • 1
Jens Bannmann
  • 4,845
  • 5
  • 49
  • 76

1 Answers1

3

The answer to this question is a moving target. As time progresses and PATCH either becomes more or less popular, the systems in the network may or may not support it.

Generally only the network entities that will care about HTTP verbs will be OSI Level 3 (IP) and up devices (firewalls, proxies). Some of those are 'dumb' in the sense that they do not inspect the OSI Level 4 (TCP). Others are 'smart' and can do protocol-level enforcement. For example, they will prevent you opening port 80 and send STMP messages.

Even if a device is 'smart', it still can be configured to allow or not allow more uncommon HTTP verbs like PATCH. So now we must factor in the security posture of the organization hosting the device. Places with open wifi like Starbucks and Airports may be quite draconian and lock down security. Same with some corporations especially if they deal with sensitive data (financial, personal info).

The upshot is that depending on the demographic for your users, PATCH might be problematic if you do not have a fallback mechanism. I would consider restricted users in the following domains more likely to have issues: sensitive corporate environments, schools, military organizations.

Edgar
  • 1,174
  • 8
  • 9