Re: [whatwg/fetch] PATCH verb (#50)

To support @annevk as a different implementer:

Among the many values shared by different browser vendors, two of the most important driving factors are:
* Adhere to standards and specifications
* Don’t break existing content

Adhering to standards promotes interoperability and provides a predictable experience for users that, no matter the browser the user chooses, the web will work consistently.

Not breaking existing content is, among other things, about ensuring that no matter the browser version the user uses, the web will work consistently.

Now, these obviously aren’t absolute; for example, browsers will diverge from standards and legacy compatibility to protect user privacy and security, when appropriate. But they are two important pillars that changes are assessed against. “Does this change the API” and “Is this spec compatible” are used to evaluate most changes.

Now, in this case, there is spec divergence in Fetch from the HTTP spec, by having it normalize. This is non-ideal: it is not spec compliant (with HTTP). But, for better or worse, it reflects what was needed to avoid breaking legacy content because bugs in implementation quickly become assumptions by web developers. You can see that yourself, as you mention that despite HTTP specifying things are case-sensitive, developers have come to rely on assuming it was case insensitive due to historic bugs in browsers. That’s unfortunate, because it means you can write code for web browsers that won’t work in non-browser contexts, because only Web browsers have this “quirk”.

Historically, this “quirk” only applied to certain methods. Other methods were left, as both Fetch and HTTP specify, case-sensitive. That was the API guarantee of older browsers, and that’s the API guarantee of other platforms.

Normalizing `PATCH` is about breaking that API guarantee. It will change how old code behaves, it will change how code behaves across different browsers and versions, and it will further diverge from the HTTP spec. These all seem like bad things.

I understand the argument here is developer ergonomics: developers (incorrectly, at least according to the specs) expect more normalization, because they’ve come to see the bugs for the other methods as features. In the [Priority of the Constituencies](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies), that’s certainly an important consideration, and is even weighed more than browser manufacturer concerns or spec purity. But that doesn’t mean it’s absolute or guaranteed to trumpet everything, but rather, it is weighed against the tradeoffs.

@annevk has rightly captured that, based on the currently available information, the current behavior is the right tradeoff, even if it may be surprising to some developers. The risks, of both breaking old code and of spec interoperability, are significant enough that even if absolute breakage isn’t quantified, as one of the foremost experts in making these tradeoff decisions, this is one where we know there is meaningful risk. The value proposition of making it easier for developers is important, but for such an issue like this, with available workarounds, it’s not appropriate to break old content and remove developer control (as normalizing would).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/50#issuecomment-674108387