Opened 16 years ago
Closed 16 years ago
#14450 closed defect (bug) (fixed)
ms-files.php generates bad content-types for REQUEST_URI's with query string
| Reported by: | chrisjean | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.0.2 |
| Component: | Multisite | Version: | 3.0 |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: |
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
@
16 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.
#3
@
16 years ago
- Cc added
- Milestone 3.0.1 → 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
@
16 years ago
- Resolution fixed
- Status closed → reopened
Re-opening to allow it to soak in trunk before potential backport.
#6
@
16 years ago
Security Note: w/o patch header injection, reported in #14594
+1 for backport beacuse of that.
#7
follow-up:
↓ 8
@
16 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...
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Updated to replace other $_SERVERREQUEST_URI instances with $file