Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PATCH verb #50

Closed
lukeapage opened this issue May 7, 2015 · 19 comments
Closed

PATCH verb #50

lukeapage opened this issue May 7, 2015 · 19 comments

Comments

@lukeapage
Copy link

@lukeapage lukeapage commented May 7, 2015

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
Copy link
Member

@annevk annevk commented May 7, 2015

No, PATCH will work as-is.

@annevk annevk closed this as completed May 7, 2015
@opengeek
Copy link

@opengeek opengeek commented Feb 24, 2016

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
Copy link
Member

@annevk annevk commented Feb 24, 2016

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
Copy link

@opengeek opengeek commented Feb 24, 2016

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
Copy link
Member

@annevk annevk commented Feb 24, 2016

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
Copy link

@opengeek opengeek commented Feb 24, 2016

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
Copy link
Member

@annevk annevk commented Feb 24, 2016

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
Copy link
Member

@annevk annevk commented Feb 24, 2016

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
Copy link

@opengeek opengeek commented Feb 24, 2016

See marmelab/restful.js#81 and the related issue at github/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
Copy link
Member

@annevk annevk commented Feb 24, 2016

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
Copy link

@opengeek opengeek commented Feb 24, 2016

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
Copy link
Member

@annevk annevk commented Feb 24, 2016

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
Copy link

@opengeek opengeek commented Feb 24, 2016

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
Copy link

@LavaToaster LavaToaster commented Mar 23, 2016

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

@mnot
Copy link
Member

@mnot mnot commented Mar 23, 2016

@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
Copy link
Member

@annevk annevk commented Mar 23, 2016

@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.

annevk added a commit that referenced this issue May 3, 2016
@broofa
Copy link

@broofa broofa commented Aug 8, 2020

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
Copy link
Member

@annevk annevk commented Aug 14, 2020

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
Copy link

@sleevi sleevi commented Aug 14, 2020

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

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 15, 2021
This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 30, 2021
This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032582
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#926658}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Sep 30, 2021
This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032582
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#926658}
pull bot pushed a commit to FairyWorld/tool_chromium that referenced this issue Sep 30, 2021
This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032582
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#926658}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 5, 2021
…only

Automatic update from web-platform-tests
[WPT] Fetch method normalization

This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032582
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#926658}

--

wpt-commits: 14f36e0dd4932d1c2a7dcfc541e1ba89e512a788
wpt-pr: 29680
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Oct 6, 2021
…only

Automatic update from web-platform-tests
[WPT] Fetch method normalization

This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032582
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#926658}

--

wpt-commits: 14f36e0dd4932d1c2a7dcfc541e1ba89e512a788
wpt-pr: 29680
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021
This CL adds tests for
https://fetch.spec.whatwg.org/#concept-method-normalize
to check that the methods not listed there are not uppercased.

This CL also adds more complete test coverage around
case-sensitiveness of request methods.

Discussion for not uppercasing "patch" method:
whatwg/fetch#50

Bug: 1228178
Change-Id: I003cd65f0c330cc5b4641d79dce721970795c994
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3032582
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Hiroshige Hayashizaki <hiroshige@chromium.org>
Cr-Commit-Position: refs/heads/main@{#926658}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

7 participants