POST request to pages returns 200 or 404

[prestonwordsworth]

When we send a POST request to a regular page via cURL with no data/body, we get 200 and a response containing the page content just as we would with GET.

When we send POST requests with arbitrary data, however, we get either 404 or 200 depending on the request body.

Is this an inconsistency to be fixed or just undocumented, but intended, behaviour?

[abcd95]

Hey @prestonwordsworth, Thanks for bringing this up!

While I would be able to suggest better if the data being sent was provided, with the information given, I can see that the behavior you're observing is the expected implementation.

Empty POST requests are treated as GET requests, returning a 200 status with page content. When POST requests include data, WordPress attempts to find a registered handler for that data pattern. With a matching handler, it returns 200, otherwise 404.

It's working as designed, though I agree with you that it could be better documented.

[prestonwordsworth]

This is very helpful to know – thank you @abcd95!

Empty POST requests are treated as GET requests, returning a 200 status with page content.

If this is intended to be used for cache invalidation, I hope there’s a way to prevent POST flood cache bypass attacks.

[pmbaldha]

As the page responses are not handled by the HTTP API, I am closing this ticket as invalid.

[swissspidy]

Removing milestone from closed ticket.

## Summary

When uploading images via the REST API with generate_sub_sizes set to false, the server still checks whether the image editor supports the uploaded image format. This causes uploads of formats like AVIF to fail with rest_upload_image_type_not_supported, even though the client is handling all image processing and the server doesn't need to generate any sub-sizes.

This PR adds a check in WP_REST_Attachments_Controller::create_item_permissions_check() to skip the server-side image editor support check when generate_sub_sizes is explicitly false.

## Changes

• class-wp-rest-attachments-controller.php: After the wp_prevent_unsupported_mime_type_uploads filter is applied, check if generate_sub_sizes is false and bypass the image editor support check if so.
• rest-attachments-controller.php (tests): Two new tests:
  • test_upload_unsupported_image_type_skipped_when_not_generating_sub_sizes — verifies upload succeeds with generate_sub_sizes=false
  • test_upload_unsupported_image_type_enforced_when_generating_sub_sizes — verifies upload still fails with generate_sub_sizes=true

## Related

• Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/76371
• Gutenberg Issue: ​https://github.com/WordPress/gutenberg/issues/76369
• Trac: https://core.trac.wordpress.org/ticket/62717

## Test Plan

• [ ] Run PHP tests: vendor/bin/phpunit tests/phpunit/tests/rest-api/rest-attachments-controller.php --filter="test_upload_unsupported_image_type"
• [ ] Verify the two new tests pass and existing tests still pass

## Proposed SVN Commit Message

Media: Skip server image support check when not generating sub-sizes.

When uploading images via the REST API with `generate_sub_sizes` set to `false`, the server still checks whether the image editor supports the uploaded image format. This causes uploads of formats like AVIF to fail with `rest_upload_image_type_not_supported`, even though the client is handling all image processing and the server doesn't need to generate any sub-sizes.

Skip the server-side image editor support check in `WP_REST_Attachments_Controller::create_item_permissions_check()` when `generate_sub_sizes` is explicitly `false`.

See also https://github.com/WordPress/gutenberg/issues/76369 and https://github.com/WordPress/gutenberg/pull/76371.

Props adamsilverstein, westonruter, andrewserong.
Fixes #64836. See #62717.

## Proposed SVN Commit Message

Media: Skip server image support check when not generating sub-sizes.

When uploading images via the REST API with `generate_sub_sizes` set to `false`, the server still checks whether the image editor supports the uploaded image format. This causes uploads of formats like AVIF to fail with `rest_upload_image_type_not_supported`, even though the client is handling all image processing and the server doesn't need to generate any sub-sizes.

Skip the server-side image editor support check in `WP_REST_Attachments_Controller::create_item_permissions_check()` when `generate_sub_sizes` is explicitly `false`.

See also https://github.com/WordPress/gutenberg/issues/76369 and https://github.com/WordPress/gutenberg/pull/76371.

Props adamsilverstein, westonruter, andrewserong.
Fixes #64836. See #62717.

Mark ready for commit

[adamsilverstein]

In 61980:

Media: skip server image support check when using client-side media.

When uploading images via the REST API with generate_sub_sizes set to false, skip server support checks since processing is handled on the client side. Fix an issue where uploads of formats like AVIF fail with rest_upload_image_type_not_supported, even though the client will handle all image processing and the server doesn't need to support the format.

See also ​https://github.com/WordPress/gutenberg/issues/76369 and ​https://github.com/WordPress/gutenberg/pull/76371.

Props adamsilverstein, westonruter, andrewserong, mukesh27.
Fixes #64836. See #62717.