Opened 8 years ago
Closed 6 years ago
#38733 closed defect (bug) (fixed)
REST API: Maintenance Mode sends HTML in request.
Reported by: | TimothyBlynJacobs | Owned by: | kadamwhite |
---|---|---|---|
Milestone: | WordPress.org | Priority: | normal |
Severity: | normal | Version: | |
Component: | WordPress.org Site | Keywords: | needs-codex |
Focuses: | rest-api | Cc: |
Description
If a request is made to the API while the site is in maintenance mode, the text is just echoed back to the client.
Seems like this should be sent as a WP_Error.
Change History (10)
#3
@
8 years ago
XMLRPC does the same thing:
$ http POST https://nylen.io/wp-dev/xmlrpc.php HTTP/1.1 503 Service Unavailable Connection: close Content-Encoding: gzip Content-Length: 242 Content-Type: text/html; charset=utf-8 Date: Wed, 09 Nov 2016 17:11:28 GMT Retry-After: 600 Server: Apache/2.2.22 (Debian) Vary: Accept-Encoding this is the content of .maintenance <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Maintenance</title> </head> <body> <h1>Briefly unavailable for scheduled maintenance. Check back in a minute.</h1> </body> </html>
This is very early in the load order and it would be difficult to fix without a hack like checking the request URL for /wp-json([/?]|$)
.
#4
@
8 years ago
Yeah, I think you'd essentially have to print the rest prefix variable in the maintenance file, and then check for either that prefix or the rest_route query arg.
#5
@
8 years ago
I don't think this is a big deal, I think this is akin to something like NGINX throwing a 502 error page is PHP is not available, etc - in these cases, clients have to handle non-json responses at the level above WordPress "normal" responses.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#8
@
8 years ago
- Milestone changed from 4.7 to Future Release
I agree it's less than ideal, but since 1) xmlrpc already has this behavior 2) wp_maintiance
runs before 99% of WordPress is loaded, so it's much harder to check if something is a rest request 3) the http status code is sent so clients know this wasn't a successful request.
Actions we should take for 4.7:
- Ensure that the http code is documented
- Ensure that any libraries we know about account for the status code for maintenance.
#9
@
8 years ago
- Component changed from REST API to WordPress.org site
- Keywords needs-codex added; needs-patch removed
- Milestone changed from Future Release to WordPress.org
- Owner set to kadamwhite
- Status changed from new to assigned
This still needs documenting on the API handbook. (There is, alas, no real keyword here, so needs-codex
will do.)
Anyone care to test the behaviour with the XMLRPC API?