Description: ------------ When defining a mime type in setContentType(), it is verified by HTTP_Download, but incorrectly. If the mime type contains a number (e.g. video/mp4,video/mp3), the script throws a Pear error. Patch: --- Download_old.php 2010-08-14 21:37:07.000000000 +0200 +++ Download.php 2010-08-14 21:37:50.000000000 +0200 @@ -554,7 +554,7 @@ */ function setContentType($content_type = 'application/x-octetstream') { - if (!preg_match('/^[a-z]+\w*\/[a-z]+[\w.;= -]*$/', $content_type)) { + if (!preg_match('/^[a-z]+\w*\/[a-z0-9]+[\w.;= -]*$/', $content_type)) { return PEAR::raiseError( "Invalid content type '$content_type' supplied.", HTTP_DOWNLOAD_E_INVALID_CONTENT_TYPE Test script: --------------- $dl = new HTTP_Download(); $dl->setFile($file); $dl->setContentDisposition(HTTP_DOWNLOAD_ATTACHMENT, basename($file)); $dl->setContentType('video/mp4'); $dl->send(); Expected result: ---------------- Correct mime type during download. Actual result: -------------- Mime type is not set.

Update: video/3gpp does not work, video/mp4,audio/mp3 works without patch.

Thanks for the patch Jens

This error is still present in 1.1.5 . The problem is, that the Mime Type "video/3gpp" (a video format commonly used by mobiles) is valid, but rendered invalid when using HTTP_Download. I can't set this mime type. Here is a diff for 1.1.5 to fix it: $ diff Download.php Download_old.php 600c600 < if (!preg_match('/^[a-z]+\w*\/[a-z]+[\w.;= -]*$/', $content_type)) { --- > if (!preg_match('/^[a-z]+\w*\/[a-z0-9]+[\w.;= -]*$/', $content_type)) { Best regards

Added patch svgSupport.

There are more valid mime types that can not pass this test. I found that the only valid mime type for .svg files (image/svg+xml) doesn't pass the test too... I've changed the patch accordingly.

Nice catch kingsquare. I found additional mime types that are now considered correct with your patch: epub files, application/epub+zip fb2 files, text/fb2+xml xhtml files, application/xhtml+xml

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.