PATCH verb

[lukeapage]

Should the patch verb be included in the spec? (https://tools.ietf.org/html/rfc5789)

here -
https://fetch.spec.whatwg.org/#concept-method-normalize

and
https://fetch.spec.whatwg.org/#http-network-or-cache-fetch

If request's body is null and request's method is `HEAD`, `POST`, or `PUT`, set contentLengthValue to `0`.

[annevk]

No, PATCH will work as-is.

[opengeek]

I think there is confusion here. PATCH is not explicitly listed in the HTTP verbs for normalization, which is the main problem. This means it is not normalized to uppercase like the rest of the HTTP verbs, and thus if a library attempts to use patch (lowercase), everything comes to a screeching halt, since the lowercase patch is not in the allowed methods for CORS. If the documentation can be modified to explicitly include PATCH in the list of HTTP verbs to normalize, I think this issue can be resolved easily.

[annevk]

HTTP verbs are case-sensitive. That we normalize a couple of them is already, strictly speaking, against the rules, but we have to do so for compatibility. If you want to use PATCH, write PATCH. If you want patch, write patch. If you want Patch, write Patch. Etc. None of this has anything to do with CORS, they should all work equally well.

[opengeek]

This is ridiculous for consistency when writing code that interacts with fetch. Yeah, we normalize all HTTP methods, except PATCH BTW. I'm not following your justification, at all.

[annevk]

Why? Just write the verb in the correct case and there's no issue. (And we're not even close to normalizing all known HTTP methods, let alone all possible HTTP methods.)

[opengeek]

Because every library that exists that adopts fetch or might adopt fetch in the future, already expects the normalization of HTTP verbs. When they make the switch to fetch, everything appears fine, until they realize that only PATCH is not normalized downstream. This is the only typical RESTful method that is NOT normalized and the inconsistency causes hard-to-track-down bugs in production applications when they update dependencies that suddenly start using fetch instead of some previous library that normalized all known HTTP verbs.

It's about consistency and common usage.

[annevk]

Do you have some data to back that up? I would expect such libraries to adhere to HTTP and treat verbs as case-sensitive. Why would any library that deals with HTTP expect these to be byte-uppercased? That flat out contradicts HTTP.

[annevk]

Let me try this another way, I tend to agree that byte-uppercasing every verb/method would be predictable and easier, but the HTTP folks would be quite upset since we have just ruled out a ton of legitimate methods. That's why we only do it for the subset browsers were already doing this for.

[opengeek]

See marmelab/restful.js#81 and the related issue at JakeChampion/fetch#37 — we just found the bug in a production application yesterday after missing this problem when updating to the restful.js library version refactored on top of fetch. I think you can see where the confusion is carrying down from the spec.

[annevk]

What did you rely on before? You had some abstraction that uppercased everything? Or did you rely on a bug in certain browsers where PATCH is sometimes byte-uppercased in XMLHttpRequest?

[opengeek]

To be honest, i didn't follow that rabbit hole all the way down. I'm just a consumer of the restful.js library and it seemed that the bug was coming from some confusion over whether fetch should normalize the PATCH method or not, based on the spec. Seems like the authors of restful.js simply expected it to be normalized inside fetch just like the rest of the methods they were using. I'm not saying this is correct, but this seems like a problem that could easily be avoided in other projects that might be expecting this same behavior.

[annevk]

As I mentioned, we'd break projects that are using HTTP correctly and want to use patcH for some reason. Unless we switch to always byte-uppercasing all methods and effectively subset HTTP (much more than today) I rather try and hold the line.

[opengeek]

I was just trying to see if you would let go of the line for this one common method, but alas, I will go refactor their code to work without it.

[LavaToaster]

@annevk I don't suppose you have any comment on JakeChampion/fetch#243?

[mnot]

@annevk I wonder if it would help if devs got a console warning when case normalisation happened (to get them used to the idea that this is for backwards-compat, not something they can rely on for other methods).

[annevk]

@Lavoaster what you're saying makes sense, I don't know why @dgraham uses lowercase method names which are supposed to be uppercase per HTTP. I filed #260 to add examples to Fetch to illustrate the difference.

@mnot I filed #259 on that.

[broofa]

This issue should be reopened. I landed here because this reddit thread shows more developers are getting tripped up by this.

As I mentioned, we'd break projects that are using HTTP correctly and want to use patcH for some reason.

@annevk In your own words, "Do you have some data to back that up?" I.e. Do you have any examples of projects that rely on such a distinction? I'd be genuinely surprised if such exist. The vast majority of developers expect HTTP methods to be uppercase or case-independent. For those few that are aware of the distinction, relying on the fact "patch" is the one standard method that's case-sensitive would seem extremely ill-advised. Any code leveraging this quirky behavior would have to be considered an inelegant hack, at best (imho).

I'm with the other commenters here - I don't understand the current rationalization for maintaining this. Yes, the HTTP spec says methods are case-sensitive, but the Fetch authors have clearly decided to ignore that by normalizing the standard HTTP methods. Leaving "patch" as the odd one out makes no sense.

[annevk]

The normalization described at https://fetch.spec.whatwg.org/#concept-method-normalize is for a select set of methods that have been normalized as such since browsers started allowing custom HTTP methods. Rationale is detailed below in notes and examples.

[sleevi]

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, 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).