By: John Lawler
Date: 2012-02-09
Time: 23:57
|
OPENTBS_DOWNLOAD failsDuring my recent tests with OpenTBS, I've been able to get my output documents only using code like this:
(which successfully writes a new file out to the web server directory, as expected). If I try instead to use this (which is what I'll usually need in production):
or
I get no results. In Firefox, I'll see a "Problem loading page" and "File not found" that references the php script I'm using to produce the template, so of course the file is available. I have varying other specific failures if I use Chrome or IE, but none of them work I don't know where to go from here. I don't see any error detail in my PHP log or in my webserver (LightTPD on Windows). I've also turned on these debugging steps which don't seem to shed any light on the situation:
So any suggestions on what to check to troubleshoot this or any guesses as to what the actual problem is? |
||||
By: Skrol29
Date: 2012-02-10
Time: 00:45
|
Re: OPENTBS_DOWNLOAD failsHi John,
First of all, check that you have the error_reporting() set to (E_ALL ^ E_STRICT). If you cannot see any PHP error with OpenTBS, then then try with;
|
||||
By: John Lawler
Date: 2012-02-10
Time: 19:42
|
Re: OPENTBS_DOWNLOAD failsI've concluded that this problem is somehow being caused by my installation of lighttpd on Windows 7 with PHP. I don't know what's causing it, but I have much bigger problems to deal with at the moment.
I was able to do very simple tests on Apache on Linux and IIS on Windows and had both of them succeed (even the OpenTBS demo features don't work on my lighttpd installation, but they did on the other two platforms I tested). If anyone has any experience running TBS & OpenTBS on Windows w/ lighttpd, I'd appreciate hearing that the download function works for you. |
||||
By: John Lawler
Date: 2012-08-02
Time: 19:58
|
Re: OPENTBS_DOWNLOAD failsJust to update anyone else who might run into this same problem. A few months ago, I happened to stumble on what was causing this constant problem for me when trying to execute the critical:
$TBS->Show(OPENTBS_DOWNLOAD, $file_name); command after completing a successful merge. It turns out I was using lighttpd (on Win 7) in a regular CGI (not FastCGI) setup (this is just for development work). PHP in Windows was setup with the default cgi.fix_pathinfo in php.ini set to 1, but with lighttpd, at least in my environment, with regular CGI, that must be set to 0 for things to work properly. Once I changed that, things started working again properly for me, even on the development system. Now, however, I've uncovered (I think I first saw this 2 or 3 months ago too) another potential problem where I cannot for the life of me get downloads to complete using the same TBS command above when using IE7 or IE8 (and probably 6). IE9 works fine, as does Firefox & Chrome (latest versions). When I add
I see a big dump of data, including the main XML body of the document (followed by a bunch of binary data at the very bottom), but the strange part is that it looks more or less exactly the same in a browser that works (Chrome) vs. a browser that doesn't IE8. I just don't think this is a simple PHP or TBS problem -- it feels more like it has to do with the browser interacting with the server with something at a header (or similar) level that's causing IE8 to reject the download and fail on it. The specific behavior of IE8 in this case is a regular download window pops up in the background saying "Getting File Information: [filename].php from www.mywebsite.com", and then a new exception window immediately pops on top of that one titled 'Windows Internet Explorer' with this content: Internet Explorer cannot download [filename].php from www.mywebsite.com. Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later. This seems to me to be some sort of weird interaction in the background. I'd suspect the cgi.fix_pathinfo situation I just described above, except when that was broken on my dev. system, *no* browsers would work on a download (I think they actually did display similar behavior to what I'm describing IE8 doing now). Now my problem seems to only happen with IE7/8 on a system where I don't think I've ever had a problem w/ FF & Chrome downloading TBS output. I've also had an attempt at looking at the detailed access logs on the IIS server where this problem exists and this doesn't seem helpful. Even the failed connections (using IE8) show a 200 OK status (and otherwise look pretty identical to the good attempts with IE9). Skrol, do you have any idea where I can go next to troubleshoot this problem? As always, I appreciate your expertise and assistance. |
||||
By: Skrol29
Date: 2012-08-02
Time: 22:05
|
Re: OPENTBS_DOWNLOAD failsHi John,
Thank for your information about the previous problem. I suspect your new problem to be because of HTTP headers. Can you note the HTTP headers sent by the script for the download ? (I use the FireFox extension LiveHttpHeaders http://livehttpheaders.mozdev.org ) Then, can you replace :
And see if it is working better with IE. |
||||
By: John Lawler
Date: 2012-08-03
Time: 22:45
|
Re: OPENTBS_DOWNLOAD failsSkrol, thanks for the suggestion.
I followed up on this, then looked at another TBS page I had which had nothing to do with OpenTBS and saw I was having the same problem there, and thus eliminated OpenTBS as a direct source of the problem. After hunting this down for some time, it turns out this was caused by that fairly well-known problem with IE versions prior to 9 when you try to download a file over an SSL connection (I probably never mentioned the problem happened on an SSL connection -- I never attached significance to that) if certain cache headers are not set properly. It appears you may have been aware of this issue, because your combination of headers above seems to work, even in the SSL situation. It does appear that you must be using different cache control settings by default in the OPENTBS_DOWNLOAD mode. So I would suggest possibly changing those in a later version if you're not aware of any other problems that might cause your users. I wrote up part of my experience chasing this problem down (your suggestion above did not immediately help me because it appeared not to work due to another silly option I had set on one of the IE browsers I was testing with) here: http://tgice.com which links to an MSDN article with more explanations. You probably wouldn't learn much if anything from it, but I thought I'd post anyway for other users who may run into the same problem. Thanks again for your help. |