Opened 15 years ago
Closed 14 years ago
#14450 closed defect (bug) (fixed)
ms-files.php generates bad content-types for REQUEST_URI's with query string
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.0.2 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Multisite | Keywords: | has-patch |
Focuses: | Cc: |
Description
File requests of the type /subsite/files/style.css?ver=1 produce a bad content-type output. The request has to be for a multisite subsite as the request has to pass through wp-includes/ms-files.php.
The problem is caused by a call to wp_check_filetype that is passed an argument of $_SERVER['REQUEST_URI'] rather than $file. Since this variable contains the querystring of the request, it causes a failure of the regular expressions that are used in wp_check_filetype function.
This problem isn't present for all files as a fallback to mime_content_type is present, and that function is called with the correct argument.
Files with extensions of CSS are good examples of the problem as the mime_content_type function returns a type of text/plain in these cases. However, I have seen some servers that will return content-types such as "text/css?ver=1".
Attached is a patch that fixes this improper argument issue. It is built off of [15473].
Attachments (1)
Change History (10)
#1
@
15 years ago
I just updated the patch to replace two other instances of $_SERVER['REQUEST_URI'] with $file as these uses would also fail in the event that the request has a query string.
#2
@
15 years ago
- Milestone changed from Awaiting Review to 3.0.1
I didn't test, but that looks ok to me.
#3
@
15 years ago
- Cc westi added
- Milestone changed from 3.0.1 to 3.0.2
Looks sane.
Would like to soak this in trunk before backporting to 3.0.x moving into 3.0.2 for that purpose.
#5
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Re-opening to allow it to soak in trunk before potential backport.
#6
@
14 years ago
Security Note: w/o patch header injection, reported in #14594
+1 for backport beacuse of that.
#7
follow-up:
↓ 8
@
14 years ago
Also, I closed #14594 even though it's not, technically, fully fixed yet... But since it was ignored for two months, I figured security is no longer a priority...
Updated to replace other $_SERVERREQUEST_URI? instances with $file