WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 5 weeks ago

#46311 new defect (bug)

Image upload issues in Gutenberg with IIS

Reported by: talldanwp Owned by:
Milestone: Future Release 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 (4)

#1 @joemcgill
12 months ago

  • Milestone changed from Awaiting Review to 5.3

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.

#2 @syned
11 months 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 @desrosj
6 months 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 @Otto42
5 weeks 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:

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.

Note: See TracTickets for help on using tickets.