v2 is a rewrite of v1. Both store pdfs. V2 gets it’s pdfs from a webservice that passes back a Base64 string, attaching the result via mime. Files can also be uploaded manualy from a file upload control.
V1 gets it’s pdfs from a local (on the same server) application that creates pdfs and leaves them on the file system for the domino app to pick up and attach. It too also has a manual upload control.
On server Dev both apps work fine. On server Test v1 works fine, but when you try and download a pdf from v2 IE (yeah, yeah, I know, but I don’t have a choice here) first asks you if you want to download it (in dev and v1 it just opens imbedded) and then errors when you try to. The same behaviour occurs with manual uploads.
Clearly there is some settup problem between the servers and the databases.
Dev is ND6.0.3, Test is ND6.5.4
v2 also has “use LZ1 compression or attachments” turmed on, where v1 doesn’t. I’ll see if that makes a difference, but boy is this one driving me nuts.
Anyone got ay other pointers?
Other manually uploaded files seem fine. Pdf’s from either system can be detached and swapped with the same results described above. And why does it work on Dev but not Test. is there some bug/feature change between 6.0.3 and 6.5.4 that would cause a problem here?
Looks like any file that is not handled by the browser directly has the problem.
I can duplicate the symptom by checking “Don’t save encrypted pages to disk” in Internet Options /tab-advanced /section-security and accessing over http.
So I’m currently working on the hypothesis that something in the app/server combination is causing IE to not cache the file. There is no code in the app to manage any http caching behaviour.
Anyone now of any server or db level settings that could effect this?
Subject: RE: Pdf Downloading Problem. Really Weird.
Ye Saga Continueth,
Previous post should have said “and accessing over https”.
OK. So I’ve now got a Dev box that’s now mirror of Test. It’s exibiting the same problems. So what have I learned now?
Problem only occurs when accessing over https. Using http I can download the files no problem.
The problem only occurs when the url to the file uses a view key rather than the doc’s UNID.
e.g.
this works: /dbpath/db.nsf/ViewName/DocUNID/$file/file.pdf
this doesn’t: /dbpath/db.nsf/ViewName/DocKey/$file/file.pdf
Yes, the first sorted column in the view contains the DocKey.
To recap: There is no problem if the browser can handle the file directly, e.g. it’s a .txt or .gif file. The problem occurs when the file needs to be passed to a third party, e.g. a .pdf, .doc file etc.
It’s also dependent on the browser settnigs. For some users there is no problem, for others there is. This is depended on the client machine settings (via windows profile), not the username & password supplied to my app. e.g. Alice has the problem on her machine and Bob does not. Alice walks over to Bob’s machine and opens a browser while still logged into windows as Bob. Alice logs into the app as her. She can download files no problem. Conversly if Bob uses Alices machine in the same way, he can no longer download files. If they both log out of windows and log in again with their own ids they are back to square one. Alice cannot download files, Bob can.
As I mention on that blog entry, i’m tackling the problem from the Internet Explorer side of things, but i’m still not happy that Domino returns different results to two urls that I had previously thought to be eqivalent.
I’ll keep this thread updated if I get any more info.
This problem aside, I think you are going to encounter all kinds of problems in applications if Dev, Test and Production use different versions of Notes…
Subject: RE: Pdf Downloading Problem. Really Weird.
Not an ACL issue as far as I can tell. The ACLs are not identical as the v2 app is not identical. I’ve investigated that angle pretty thoroughly. I can download other file types, it’s just pdfs that cause the problem.
Yeah the dev/test server thing is not ideal, prod is same as test. Replacement dev server is on the way ;). Still there is nothing in the code that I’m aware of that should cause this problem, it should work fine. It’s worked fine on other dev 6.5.x servers and on 7 server.