Not able to download pdf files from Media

Next topic

Author	Message
Iain MacLean	Monday 26 January 2004 5:04:39 pm Hi I'm having trouble getting ezpublish-3.3-2 to find PDF files after I upload them into the Media folder or a file library section I have created in the Content area. I can upload MSOffice and OpenOffice docs and spreadsheets OK, and they can be downloaded, but I can't download PDF files. A link to a pdf file appears in the correct node (with the correct file name, but 0kb as the size) and there is a copy of the file in /var/site_dirctory/storage/original/text. However, when I try to download it, it get an "Object is unavailable" error. I have checked the permissions on the folders and they are OK (as I can upload, I guess that's obvious). If I re-name a pdf and give it a .doc or .sxw extension before uploading it, everything works properly. I had the same problem with eZpublish-3.3-1. I had thought it might be an Apache mime handling problem. I inserted a new AddType application/pdf in the httpd.conf, but that didn't work, either. I'm guessing it's got something to do with eZpublish not recording the new file name of the pdf in the /var directory so that it can retrieve it later, but I have no idea where to start if that is the case. It's got me stumped! Anyone have any bright ideas? Iain MacLean
Iain MacLean	Thursday 29 January 2004 12:11:48 am Still don't have a solution to this, although it appears that eZpublish is interpreting the mime type application/pdf as text/pdf, which is why it stores PDF files in /var/site_directory/storage/original/text instead of /var/site_directory/storage/original/application. If I copy the newly uploaded PDF into /var/site_directory/storage/original/application, then I can download it. Postscript files are correctly stored in /var/site_directory/storage/original/application, and text files are stored in /var/site_directory/storage/original/text. I can download both from their respective directories. It seems that the files ezbinaryfiletype.php and ezmimetype.php are the ones that control this process, especially the functions in ezmimetype.php, possibly using the array var $QuickMIMETypes = array() at the bottom of ezmimetype.php. However, that doesn't explain why PDF files end up interpreted as text/pdf rather than application/pdf. Direct download PDF export works OK, although if I don't export for direct download I get a error "You don't have permission to access /var/site_directory/storage/pdf/file.pdf on this server". The newly-created PDF file is stored in /var/site_directory/storage/pdf (as it is supposed to be), and apache has all the required permissions, but I still can't download it. I do not have pstotext installed on my server or development machine (both Linux), but I do have pdftotext installed. Could that be a possible cause? The file library is an important part of my client's site, so I would be really, really grateful of any suggestions as to the possible cause of the problem. Iain
Iain MacLean	Saturday 31 January 2004 6:44:42 pm Problem sorted. It seems to be caused by the way Opera handles the mime type of PDF files. When I tried uploading PDF files with another browser it worked fine. Both Firebird and IE6 put the PDF file in the correct directory for download. Should have tried this earlier :-(. I've seen some posts about how Netscape handles PDF files when downloading. Perhaps this is relelated? Cheers Iain

Author

Message

Monday 26 January 2004 5:04:39 pm

I'm having trouble getting ezpublish-3.3-2 to find PDF files after I upload them into the Media folder or a file library section I have created in the Content area. I can upload MSOffice and OpenOffice docs and spreadsheets OK, and they can be downloaded, but I can't download PDF files. A link to a pdf file appears in the correct node (with the correct file name, but 0kb as the size) and there is a copy of the file in /var/site_dirctory/storage/original/text.

However, when I try to download it, it get an "Object is unavailable" error.

I have checked the permissions on the folders and they are OK (as I can upload, I guess that's obvious).

If I re-name a pdf and give it a *.doc or *.sxw extension before uploading it, everything works properly.

I had the same problem with eZpublish-3.3-1.

I had thought it might be an Apache mime handling problem. I inserted a new AddType application/pdf in the httpd.conf, but that didn't work, either.

I'm guessing it's got something to do with eZpublish not recording the new file name of the pdf in the /var directory so that it can retrieve it later, but I have no idea where to start if that is the case.

It's got me stumped!

Anyone have any bright ideas?

Iain MacLean

Thursday 29 January 2004 12:11:48 am

Still don't have a solution to this, although it appears that eZpublish is interpreting the mime type application/pdf as text/pdf, which is why it stores PDF files in /var/site_directory/storage/original/text instead of /var/site_directory/storage/original/application. If I copy the newly uploaded PDF into /var/site_directory/storage/original/application, then I can download it. Postscript files are correctly stored in /var/site_directory/storage/original/application, and text files are stored in /var/site_directory/storage/original/text. I can download both from their respective directories.

It seems that the files ezbinaryfiletype.php and ezmimetype.php are the ones that control this process, especially the functions in ezmimetype.php, possibly using the array var $QuickMIMETypes = array() at the bottom of ezmimetype.php. However, that doesn't explain why PDF files end up interpreted as text/pdf rather than application/pdf.

Direct download PDF export works OK, although if I don't export for direct download I get a error "You don't have permission to access /var/site_directory/storage/pdf/file.pdf on this server". The newly-created PDF file is stored in /var/site_directory/storage/pdf (as it is supposed to be), and apache has all the required permissions, but I still can't download it.

I do not have pstotext installed on my server or development machine (both Linux), but I do have pdftotext installed. Could that be a possible cause?

The file library is an important part of my client's site, so I would be really, really grateful of any suggestions as to the possible cause of the problem.

Iain

Iain MacLean

Saturday 31 January 2004 6:44:42 pm

Problem sorted. It seems to be caused by the way Opera handles the mime type of PDF files. When I tried uploading PDF files with another browser it worked fine. Both Firebird and IE6 put the PDF file in the correct directory for download. Should have tried this earlier :-(.

I've seen some posts about how Netscape handles PDF files when downloading. Perhaps this is relelated?

Cheers

Iain

eZ debug

Timing:	Jan 18 2025 22:13:55
Script start
Timing:	Jan 18 2025 22:13:55
Module start 'layout'
Timing:	Jan 18 2025 22:13:55
Module start 'content'
Timing:	Jan 18 2025 22:13:56
Module end 'content'
Timing:	Jan 18 2025 22:13:56
Script end

Main resources:

Total runtime	0.6081 sec
Peak memory usage	4,096.0000 KB
Database Queries	55

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0047	588.0469	152.6406
Module start 'layout'	0.0048	0.0030	740.6875	39.4766
Module start 'content'	0.0077	0.5984	780.1641	436.7813
Module end 'content'	0.6061	0.0019	1,216.9453	12.1250
Script end	0.6081		1,229.0703

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0030	0.4888	16	0.0002
Check MTime	0.0012	0.1960	16	0.0001
Mysql Total
Database connection	0.0007	0.1143	1	0.0007
Mysqli_queries	0.5620	92.4202	55	0.0102
Looping result	0.0005	0.0884	53	0.0000
Template Total	0.5786	95.1	2	0.2893
Template load	0.0021	0.3447	2	0.0010
Template processing	0.5765	94.7950	2	0.2882
Template load and register function	0.0002	0.0288	1	0.0002
states
state_id_array	0.0009	0.1422	1	0.0009
state_identifier_array	0.0007	0.1182	2	0.0004
Override
Cache load	0.0017	0.2875	26	0.0001
Sytem overhead
Fetch class attribute can translate value	0.0005	0.0794	1	0.0005
Fetch class attribute name	0.0013	0.2125	3	0.0004
XML
Image XML parsing	0.0001	0.0181	1	0.0001
class_abstraction
Instantiating content class attribute	0.0000	0.0017	3	0.0000
General
dbfile	0.0015	0.2385	10	0.0001
String conversion	0.0000	0.0013	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded
1	node/view/full.tpl	full/forum_topic.tpl	extension/sevenx/design/simple/override/templates/full/forum_topic.tpl
3	content/datatype/view/ezxmltext.tpl	<No override>	extension/community_design/design/suncana/templates/content/datatype/view/ezxmltext.tpl
3	content/datatype/view/ezxmltags/paragraph.tpl	<No override>	extension/ezwebin/design/ezwebin/templates/content/datatype/view/ezxmltags/paragraph.tpl
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 8 Number of unique templates used: 4

Time used to render debug report: 0.0001 secs