Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#37946 closed defect (bug) (worksforme)

Media Uploads Hang using Chrome and HTTP/2

Reported by: pbarnhart's profile pbarnhart Owned by: jeremyfelt's profile jeremyfelt
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: Cc:


Media uploads - using both the WordPress uploaded and the default browser uploader - hang when the server is using HTTP/2. Server configured with Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2h - ALPN support confirmed, pagespeed disabled, all plugins turned off. Functions fine under current version of Microsoft Edge.

When HTTP/2 turned off at server - and no other settings modified - Chrome works fine for image uploaded. Fairly sure errors did not occur until Chrome disabled NPN support with Chrome 51, previously there were no issues uploading media via Chrome.

Change History (9)

#1 @joemcgill
7 years ago

  • Owner set to joemcgill
  • Status changed from new to reviewing

Hi @pbarnhart,

Thanks for the report and welcome to Trac. Could you provide any additional information about the kinds of error messages you are seeing, including any differences in the server responses that show up in Chrome's dev console?

#2 @pbarnhart
7 years ago

There are zero error messages in console. There are no errors in the server log. Nothing when I run a server-side debug. It simply times out. When I switch the server to HTTP 1.1 everything works on Chrome. Switch it back to HTTP/2 and Chrome 51 forward fails (other browsers do fine). And the server does respond to HTTP 1.1 requests.

With some coord I can give up access to this site and can switch server back and forth re HTTP/2 if it helps. Honestly, I hope its something stupid I did because in my day job we manage about 40+ WP sites and are ready to move to HTTP/2

Here are the header responses:

WordPress Uploader

Request URL:
Request Headers
Provisional headers are shown
Accept:application/json, text/javascript, */*; q=0.01
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
User-Agent:Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36
Form Data
view source
view URL encoded

Browser Uploader

Request URL:
Request Headers
Provisional headers are shown
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryXyknXR3wtwM2GPgO
User-Agent:Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36
Request Payload
Content-Disposition: form-data; name="async-upload"; filename="Dollarphotoclub_71447704.jpg"
Content-Type: image/jpeg

Content-Disposition: form-data; name="html-upload"

Content-Disposition: form-data; name="post_id"

Content-Disposition: form-data; name="_wpnonce"

Content-Disposition: form-data; name="_wp_http_referer"

Last edited 7 years ago by SergeyBiryukov (previous) (diff)

#3 @johnbillion
7 years ago

@pbarnhart What's the value of $_SERVER['SERVER_PROTOCOL'] on the affected site please?

#4 @pbarnhart
7 years ago


#5 follow-up: @jeremyfelt
7 years ago

Thanks for all of the info so far @pbarnhart and thanks for making the switch to HTTP/2! :)

For a basic initial comparison, we're serving HTTP/2 at WSU to ~95% of authenticated visitors now (thanks modern browsers!) and haven't seen any trouble with uploads in Chrome. However, we're on Nginx 1.11.3 rather than Apache, so it seems like that could be the right path to start troubleshooting.

If possible, would you mind sharing your Apache configuration as an attachment (publicly) or privately? It's okay if it's sanitized, but it would be nice to try to reproduce this in a VM environment.

I poked around in the Apache changelogs for the 2.4.x releases since 2.4.18 and there are quite a few bug fixes for the mod_http2 module. 2.4.18 itself happened well before Chrome made the switch from NPN to ALPN and is only one release into Apache's support for HTTP/2. See also the changelogs for the upstream project mod_h2 that donated the module to Apache as it continues to be an active project.

I didn't look into how many of those changes Ubuntu has included in recent packaging of the 2.4.18 version, but I would try to upgrade to 2.4.23 on your server before spending much time looking at other possibilities.

#6 @joemcgill
7 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner changed from joemcgill to jeremyfelt

Sounds like this is probably a server configuration issue. I'm going to reassign to @jeremyfelt to continue reviewing and leave it open for now.

#7 in reply to: ↑ 5 @pbarnhart
7 years ago

Replying to jeremyfelt:

Nailed! Updated server to 2.4.23 and media posts via HTTP/2 now working. Thanks and glad it was a simple fix on my end. Thanks for troubleshooting this and for the reminder I need to keep up with my Apache releases :-)

#8 @pbarnhart
7 years ago

  • Resolution set to worksforme
  • Status changed from reviewing to closed

#9 @swissspidy
7 years ago

  • Milestone Future Release deleted
  • Version trunk deleted
Note: See TracTickets for help on using tickets.