Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June. // The Content-type header does not make sense on GET requests, because GET
// requests do not carry any content. Nothing to filter in this case.
if ($request->isMethod('GET')) {
return $collection;
}
should be
// The Content-type header does not make sense on GET requests, because GET
// requests do not carry any content. Nothing to filter in this case.
if ($request->isMethod('GET') || $request->isMethod('HEAD')) {
return $collection;
}
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 2934152-8.patch | 2.3 KB | wim leers |
Comments
Comment #2
wim leersDiscovered in #2934149: [>=8.5] JSON API routes not specifying _content_type_format route requirement, resulting in bad DX.
Comment #3
wim leersGiven it blocks contrib, bumping to major.
Comment #4
wim leersFailing test coverage.
Comment #5
wim leersComment #7
neclimdulMakes sense. Wonder if it makes sense to include OPTIONS while we're at it though.
Comment #8
wim leersThen we should probably also add
TRACE.Comment #9
e0ipsoThis also looks good to me. Nice and simple.
+1.
Comment #10
dawehnerThis looks fine for me, too.
Comment #11
wim leers🎉
Comment #12
neclimdulTRACE has a body it just can't be a method that writes to the server so I left it out. Its a weird method to support as a CMS in reality but for the sake of correctness I'm not sure its actually is correct to exclude.
Comment #13
wim leersAre you sure?
https://tools.ietf.org/html/rfc7231#section-4.3.8 says:
Comment #14
neclimdulHmm, I must have misread something... Fair enough.
Comment #15
wim leersImproving issue title.
Comment #16
larowlanCrediting @neclimdul as his observations changed the shape of the patch
Comment #18
larowlanCommitted as a46090e and pushed to 8.5.x.
As per https://www.drupal.org/core/release-cycle-overview#current-development-c... 8.4 is in 'critical fixes only', so this can't be backported to 8.4
Comment #19
wim leers@larowlan: doesn't "criticals only for current minor" start when the beta of the next minor is released?
Comment #20
larowlanSee my comment on #2931883: Unneeded always_populate_raw_post_data requirements check while on CLI
Comment #21
neclimdulI feel like I'm not understanding the policy clearly because it seems to put site devs in an awkward position not getting major bug fixes for a possibly extended-ish period of time. Is there documentation around it or is just RM consensus?
Comment #22
xjmNormally, site developers may not get bug fixes for 4-5 weeks after the fix is committed to the production branch. During the final preparation of the minor release, this is increased to up to 6-7 weeks. Not really that much of a difference in the grand scheme of things.
Also, this is indeed an official policy as documented on https://www.drupal.org/core/release-cycle-overview, and has been applied consistently from 8.1.x on.
Thanks!
Comment #23
neclimdulThanks xjm, I guess that sort of makes sense. I hate to ask this but I'd already read it twice and I just read it start to finish 3 more times and I just can't figure out what section documents this policy. Where exactly is this prep-critical policy documented?
Comment #24
wim leersWe're talking not 4-5 weeks, not 6-7 weeks, but 14–15 weeks (committed January 7, available April 18).
I have to agree with @neclimdul here, it's not clear to me at all where this is documented. I did see this:
… which is what I based my comment in #19 on.