Make WordPress Core

Opened 5 years ago

Closed 3 years ago

#38427 closed defect (bug) (reported-upstream)

wp-cron.php: POST-request, but content-length missing

Reported by: mozai Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: HTTP API Keywords:
Focuses: Cc:

Description (last modified by desrosj)

This appears to be a return of bug #8605

Environment: WordPress 4.6.1, lighttpd 1.4.35, PHP 7.0.8

access_log: [17/Oct/2016:22:51:36 -0400] "POST /main/wp-cron.php?doing_wp_cron=1476759096.5852251052856445312500 HTTP/1.1" 411 357 "-" "WordPress/4.6.1; http://www.[omitted].com/main"
error_log: 2016-10-20 22:51:36: (request.c.1125) POST-request, but content-length missing -> 411

Other info:

  • there are no successful calls to wp-cron; it is always error 411
  • HTTP result code 411 is "Length required". RFC2616 Section 14.13 says Content-Length header "SHOULD" be included. In practice, it is not used for GET nor HEAD requests, but is expected for POST requests.
  • This error happens hundreds of times each day and oddly the error appears in a different "error_log" than expected; the webserver uses name-based virtual hosts, but the error messages are landing in the default name-less error_log file, as if not only the "Content-Length:" header is missing but also the "Host:" header.

Change History (2)

#1 @dd32
5 years ago

  • Component changed from General to HTTP API
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version changed from 4.6.1 to 4.6

Hi @mozai and welcome to Trac,

Thanks for reporting this, I suspect this will be caused by our switch to Requests in 4.6.
I've opened https://github.com/rmccue/Requests/issues/248 upstream to get the issue fixed.

Worth noting this only affects the fsockopen() transport, and not the cURL transports. A quick fix would be to enable cURL on the site.

#2 @desrosj
3 years ago

  • Description modified (diff)
  • Keywords needs-patch removed
  • Milestone Future Release deleted
  • Resolution set to reported-upstream
  • Status changed from new to closed

Looks like there is an open PR for this. I am going to close this as reported-upstream. When a new version of Requests is released, this will be included when Core receives the update.

Note: See TracTickets for help on using tickets.