Domino Icon Bug
Before I went away I meant to pass on this Domino "feature" but I must have forgotten. Can't remember who it was that mailed me but I thank them anyway. Take a file in Domino's HTML directory i.e Domino\Data\Domino\HTML and its URL. Add a space and a dot after it and Domino will present it as a download, regardless of filetype.
For example (I know it's not in the HTML directory, but it still works) take an icon file with the URL:
http://server/icons/vwicn123.gif
If you typed this in your browser you would see the image, as expected. But, if you typed:
http://server/icons/vwicn123.gif%20.
You would be asked where you wanted to save the file. Hmmm, does this matter? You could easily save the file anyway. Well, with an image, yes. But what about files that get compiled by the server and contain passwords e.g JSP or Crytal Reports files. Feature or bug? You decide.
Note: The reason I didn't make the above links to the icons on codestore is that it only seems to affect Windows machine. For example ABB's icons.
As promised here are my holiday photos for those interested.
Jake,
Anyway to force the save to disk prompt? eg-skip open from location.
also, anyway to specify a directory for the user vs them having to choose if they select save to disk?
RE: the "feature"; Although I wouldn't consider my testing complete, I am finding that this is not the case for R4.6.7 servers (of which we have a couple left).
It seems as though this "feature" does not work for attachments inside Notes databases. It works fin for files stored in the server's file system, but returns a File Not Found for attachments. Still looking for a way to do this with attachments.
It seems to not be a Lotus bug.
have a look at www.cert.org.
This happens only when you use IIS as web provider with domino.
I'm using a notes server alone and I experience no such issue.
Patrick,
It's not about using IIS as a web provider with domino.
I'm using Domino 5.0.11 and it behaves as Jake described.
In fact, when you use Domino with ISS, you DON'T see this behaviour.
Does this mean that JSP files do not get parsed by the server? If files are send to the browser without being parsed we have a serious security hole.
If files are parsed correctly there's no security problem and the server is just returning an unknown mime-type which triggers the file download option.
Ofcourse it's not the way it should be done and a 404-error should be generated. But hey, it's Domino...
Nice pics Jake.
Re: the "tuk-tuk" - is that a 3 wheeled cab? We have those in India too. they're called auto-rickshaws there... use a motorbike engine I believe. God help you if you're riding one of those things next to a truck (lorry) belching exhaust :)
Also the "padoga" in your pictures should be called a pagoda (the cone shaped structure built in memory of Buddha)
Dan
Cheers Dan. Knew I'd got the name of the pagoda wrong. Woops.
It's funny. The few days in the tuktuks we were all really scared (they have no highway code by the looks of it) but after the first week we were totally unfazed by it all ;o)
Not good for your health though, I agree. Mind you, neither is 14 nights on the booze...
This is a real problem, and it still works incorrectly using 5.0.12 on Windows servers. If you add a '.' or a '%20.' to the end of a file in the filesystem, you'll get a response from Domino with a Content-Type of www/unknown and the raw contents of the file along with it. If the file was supposed to be parsed (as a jsp, asp, or pl file, for example), it will not be, and the source of those files will come right down to the browser for local review.
Jake and Vitor are correct, and Patrick is missing something in the exchange. It's when you are *not* using the IIS http stack that the problem occurs. For those who are not using any interpreted or parsed stuff from the file system, this is not a big deal. For those who are, this might be a huge deal, depending on what's in those files...
Digging around on LDD, I found an ancient post from 1999 that rings a bell.
{Link}
The question being asked about isn't important, it's the bug about the trailing character that seems like almost the same issue, going back 4 years!
I really hope IBM takes this a bit more seriously than they have so far.