Opened 8 years ago
Closed 6 years ago
#38427 closed defect (bug) (reported-upstream)
wp-cron.php: POST-request, but content-length missing
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.6 |
Component: | HTTP API | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
This appears to be a return of bug #8605
Environment: WordPress 4.6.1, lighttpd 1.4.35, PHP 7.0.8
Seen:
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
@
8 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
#2
@
6 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.
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 thecURL
transports. A quick fix would be to enable cURL on the site.