Opened 5 years ago
Closed 6 months ago
#46311 closed defect (bug) (wontfix)
Image upload issues in Gutenberg with IIS
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | Media | Keywords: | needs-patch |
| Focuses: | Cc: |
Description
Transferring this Gutenberg github issue here: https://github.com/WordPress/gutenberg/issues/12532
Many users are reporting they're able to upload images using the media uploader, but not in Gutenberg. The common thread seems to be that the server is IIS.
Change History (5)
#2
@
5 years ago
Just ran into this issue myself on an IIS server. Here's the response from the console (http://www.example.com/wp-json/wp/v2/media):
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.example.com/wp-json/wp/v2/media/498">here</a></body>
{"id":498,"date":"2019-05-17T10:47:33",.....}
HTML at the top is caused by 302 redirect in class-wp-rest-attachments-controller.php:206.
$response->header( 'Location', rest_url( sprintf( '%s/%s/%d', $this->namespace, $this->rest_base, $id ) ) );
I don't know if there is a way to prevent IIS from outputing this HTML for 302 redirects. I tried just commenting out this line and it fixes the issue, but I'm not sure if it could mess things up somewhere else, so it might not be a good fix.
#3
@
5 years ago
- Keywords needs-patch added
- Milestone changed from 5.3 to Future Release
Unfortunately, without a working understanding of this issue or a patch, this one needs to be punted.
If someone can debug and provide a working patch before 5.3 RC1, it can be considered for a move back to 5.3.
#4
@
4 years ago
The problem, by and large, is that older versions of IIS do some HTML work when they see things like the location header.
The REST specification generally uses the 201 response with a location header to indicate that a new resource is created. This is the standard for such a response. You upload a file, server responds with 201-created and where the new resource is.
References:
https://tools.ietf.org/html/rfc7231#section-6.3.2
https://restfulapi.net/http-status-201-created/
IIS, especially older versions, sees a Location header, assumes it's for a redirect, and injects some HTML in the response for (extreme) backwards compatibility with older browsers that didn't follow redirects.
Reference:
https://stackoverflow.com/questions/12074730/w7-pro-iis-7-5-overwrites-php-location-header
There's probably some ways to work around this with IIS that the stackoverflow topic doesn't cover, but the main ones are:
- Don't use IIS, switch to Apache or nginx or something else.
- Use a modern version of IIS, or possibly a hotfix that allows you to turn this off (https://support.microsoft.com/en-us/help/980363/a-hotfix-is-available-that-adds-features-to-the-fastcgi-module-in-iis) Note: Hotfix may no longer be available since all Microsoft resources tell you to switch to Windows 10 and more modern systems.
And that's pretty much that, as far as my research can find. The short of it is that REST and the HAL specification has been around for long enough to be considered standard, so sending a 201 with a Location header is the correct practice for resource creation. If you're using a webserver older than that specification and which is still including backwards compatibility support that probably only applies to Netscape 1.0, then I would suggest upgrading to a webserver which has been updated since after 2014.
#5
@
6 months ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from new to closed
Based on @Otto42's research, this seems like a strong candidate for wontfix. The issue is caused by a non-standard behavior on servers that predate current standards. The labor for us to resolve a relatively obscure issue that is best resolved upstream doesn't seem reasonable. Feel free to reopen if you feel differently!
Thanks for getting this moved, @talldanwp. It would be helpful if anyone who is experiencing this issue could copy the full console error here for more debugging. What's interesting is that it only happens in Gutenberg, which leads me to believe it may be something specific to the file upload component which uses the REST API as the back end rather than the traditional admin ajax back-end that is used by the media modal.