Topic: Local PDF download becomes corrupt (Read 5340 times)

techadept · « **on:** 22 July 2008, 00:10 »

issue:

Download of PDF file stored locally on the web server becomes corrupt (0 byte size) after download.

environment:

wp-downloadmanager v1.31
wordpress v2.6 and v2.51

scenario:

PDF file verified as readable
File uploaded to server as BINARY via FTP
File added to wp-downloadmanager via admin subpage
select file download link from "recent downloads" widget (or any other file download link)

expected results:

file downloads and is readable

actual results:

file appears to download normally but upon file download completion, the file ends up as a zero byte size file.

work around:

Using redirect to file permits the file to be accessible (however, on my production server which is an IIS server, it causes the user to be prompted with an MSCHAP handshake.)

Tested this on both a 2.5.1 installation of Wordpress and 2.6. (The 2.6 is my dev environment as my production is not ready to launch 2.6 with some of the oops bugs that got left in 2.6... once I verify that I can upgrade to 2.6 and know all of the bug fixes, I'll move the production system to 2.6)

Currently I have the file hidden on my production system, but I've attached the PDF file so you can attempt to replicate the problem.

Any ideas how to solve this file output bug?

techadept · « **Reply #1 on:** 22 July 2008, 00:11 »

Your file upload process on the forums did the same thing on the upload that happens on my website on the download. 0 file size.

PM me and I'll PM you back a direct URL to the file itself.

GaMerZ · « **Reply #2 on:** 22 July 2008, 05:21 »

This forum is by SMF, or is there something wrong with the pdf file?

Because I got no problem uploading pdf using downloadmanager on my localhost (I just tested it) and I got no problem uploading pdf to this forum (see attachment)

techadept · « **Reply #3 on:** 22 July 2008, 07:01 »

That's what I'm saying. This PDF, while readable, for some reason is getting corrupted by the upload/download process.

Case in point, I tried to upload the image again, and instead of uploading, it gets stopped at 0 bytes.

GaMerZ · « **Reply #4 on:** 22 July 2008, 09:14 »

That means this PDF has a problem. I got no problem uploading my PDF.

If even SMF has a problem, then I think the problem is really your pdf.

techadept · « **Reply #5 on:** 22 July 2008, 14:00 »

But why would the PDF be readable until uploaded/downloaded?

That's all I'm asking.

GaMerZ · « **Reply #6 on:** 22 July 2008, 14:25 »

that I have no idea, I would guess it maybe a header error within the pdf.

Ttech · « **Reply #7 on:** 22 July 2008, 20:12 »

permission?
problem?

techadept · « **Reply #8 on:** 23 July 2008, 00:25 »

Quote from: Ttech on 22 July 2008, 20:12

permission?
problem?

Ttech,

I appreciate the suggestion. I do not have problems with any other files and I verified that this file has the same security settings as the other files in the directory (i.e., security inherited from folder, not custom). I also have the files in a folder on the internet which is accessible (no read restrictions), and I can link to the file directly without a problem. I only have a problem when the file is delivered using the Output to File delivery method. So the problem can't be security (at least, not file security)

Also, I cannot use the Redirect to File delivery method because when I do, I am prompted for MSCHAP authentication, which I want to get away from (and since an anonymous user can directly link to the file, the prompt for authentication has to do with PHP or with the plugin, my guess would be PHP, but I'm not yet knowledgable enough to fix that...)

I unfortunately do not understand enough about header errors to be able to see where Lester's comment should take me. If I understood that much, I wouldn't have asked for help, I would have just fixed the problem and reported the solution.

Maybe I'm naive, but my thinking goes something like: If the file is completely readable and has no errors prior to going through the Output to File delivery method, but after that it ends up as a 0 byte file, then something in the delivery method is corrupting the file. If the delivery method is the cause, check with the author of the application to see if they have any suggestions.

This is why I offered to provide a direct link to the file so that the author could experiment with it, but he declined to look at the file. If you (Ttech) would like to get a copy of the PDF to verify that I'm telling the truth about the file being readable prior to going through the Output to File download method, I'm happy to provide a direct URL to the file.

The problem only occurs with this file, which suggests to me that the Output to File method does something to interpret the file it is sending, but since I don't know enough about the process to figure out the answer on my own, I was hoping to get assistance from someone here.

GaMerZ · « **Reply #9 on:** 23 July 2008, 06:39 »

Quote

The problem only occurs with this file, which suggests to me that the Output to File method does something to interpret the file it is sending, but since I don't know enough about the process to figure out the answer on my own, I was hoping to get assistance from someone here.

That means when you try other PDF it works fine?

Output To File: PHP will open up the file and read the contents the file and then output the contents to your browser for it to be interpreted. This method is known to have problems with large files as well as possibility of corrupting files.
Redirect To File: Simply add a header that redirects you to the file. I am using this method personally.

techadept · « **Reply #10 on:** 23 July 2008, 14:58 »

Quote from: GaMerZ on 23 July 2008, 06:39

That means when you try other PDF it works fine?

Yes.

I'll start investigating why Redirect to File causes the MSCHAP handshake. Once I solve that, I guess that's my solution. Any suggestions on why the Redirect to File method causes the handshake?

GaMerZ · « **Reply #11 on:** 23 July 2008, 15:05 »

How about try typing the direct url to the file in your browser, the the MSCHAP handsake appear?

Ttech · « **Reply #12 on:** 26 July 2008, 22:35 »

May I ask what the MSCHAP handshake is?

techadept · « **Reply #13 on:** 26 July 2008, 23:40 »

Quote from: Ttech

May I ask what the MSCHAP handshake is?

It stands for Microsoft Challenge Handshake Authentication Protocol

Let's assume the PDF is located at 'd:\inetpub\wwwroot\blog\wp-content\files\mypdf.pdf'. This can be reached by using the URL 'http://www.domain.ext/blog/wp-content/files/mypdf.pdf'. Let's also assume that I use Output File method, and my URL looks like 'http://www.domain.ext/blog/?dl_id=20'.

If I change from Output File to Redirect to File, then the URL is still 'http://www.domain.ext/blog/?dl_id=20', but now that I'm redirecting, I get an MSCHAP handshake:

However, if I navigate to the URL directly for Download #20 ('http://www.domain.ext/blog/wp-content/files/mypdf.pdf'), the file downloads without becoming corrupt.

This is why I offered to provide the PDF file, so that you could attempt to replicate the issue yourself. However, if you don't have an IIS server to do the testing, it might not work. I'll eventually replicate the entire environment to my freebsd web server and attempt to replicate the (corruption) problem, but it's a low priority for me. Figuring out why I get the MSCHAP handshake is of higher priority so that I can convert to Redirect to File. Plus, since the number of files I need to manage is significantly higher than your plugin is intended for, I will eventually have to re-write it, but I don't think I'll do that until I reach 150-200 files.

Also, on IIS, I cannot upload files using "File Add". Again, this has to be a permission thing (probably PHP related and not specific to your plugin), but it's not something I've figured out yet.

Ttech · « **Reply #14 on:** 27 July 2008, 04:43 »

techadept: Thanks a bunch.

That helps a lot.

GaMerZ · « **Reply #15 on:** 27 July 2008, 12:03 »

Hmm, unfortunately I do not have IIS server to play with. I have been thinking since you are able to access the URL directly means the user (you) is already auth to access the URL. In the case of the URL redirect, the script is redirecting on the user behalf and hence the script is "technically" accessing the url and not the user (you) and perhaps that may be the reason of the MSCHAP.

techadept · « **Reply #16 on:** 27 July 2008, 15:20 »

Quote from: GaMerZ

I have been thinking since you are able to access the URL directly means the user (you) is already auth to access the URL. In the case of the URL redirect, the script is redirecting on the user behalf and hence the script is "technically" accessing the url and not the user (you) and perhaps that may be the reason of the MSCHAP.

Quote from: techadept

(and since an anonymous user can directly link to the file, the prompt for authentication has to do with PHP or with the plugin, my guess would be PHP, but I'm not yet knowledgable enough to fix that...)

Yup, I've already arrived at that conclusion. Most likely it's PHP, or possibly the configuration of the website (IIS). I just came up with a way that I might be able to troubleshoot the issue. I'll have to play around with it and see if I can figure it out.

GaMerZ · « **Reply #17 on:** 27 July 2008, 15:42 »

Do let me know if you manage to figure it out =D

Thanks in advanced

Ttech · « **Reply #18 on:** 27 July 2008, 19:57 »

I'm going to get my friend here on this post, as he knows IRSS and Windows Server Stuff better then I. No guarantee, But I'll try.

Lester Chan's Forums

News:

Author Topic: Local PDF download becomes corrupt (Read 5340 times)