I forgot to add :
Since previously the application was running on a Win2K server, it may be that this Win2K
server just "shared" (windows-like) the directory where the .ics files were located, and
this being in a local LAN, that the client were just writing the files there via a Windows
network file mechanism (and nothing to do with HTTP thus).
That sounds quite unsafe and limited, but in a small intranet may be acceptable.
If such was the case (and again the client setup should contain a hint), then maybe all
that's missing is to "share" the new directory under Tomcat where you put the files.
Tomcat won't be involved in the writing part, so it should not stand in the way, at least
as long as when a client writes there, the permissions don't prevent Tomcat from reading
the files (for the "download" part).
Don't take this as a recommendation of how to do it.
André Warnier wrote:
Right.
There should be some setting/parameter corresponding to the Thunderbird
plugin, which indicates /how/ it is trying to write files to the server.
In Options..Advanced..Config Editor ?
I find some traces there in my Thunderbird setup, of parameters starting
with "SyncKolab".. (That may be something else though)
The point which several people were trying to make here is :
Any "sane" webserver setup will never allow a user to /upload/ files to
the server, just by specifying their URL. That is because it is
potentially a very big security hole.
(One generally does not want the first miscreant around to deface one's
server by loading his own pages or applications)
It is /possible/ to allow this (and there are even special HTTP commands
to do that), but you need to add something to the server, in terms of
additional modules to handle such uploads, and a special (and careful)
configuration to go with it.
It is not sufficient to just put the files somewhere where they can be
seen and retrieved by a browser, and make them writeable. Thankfully.
(Note that all this is not specific to Tomcat. Any reasonable webserver
is like that.)
One such fairly standard server add-on, in the case of Tomcat, is the
DAV application. It is available on the Tomcat website, but not as part
of the standard download (I think), and it is certainly not installed by
default.
It is not the only way, and maybe this particular plugin expects the
webserver to run an application which comes along with the plugin. But
again, you'd need to install it on the server, it will not be there by
default.
In any case, one would expect, either in the plugin documentation or in
the parameters somwhere on the client, to find a hint as to how the file
upload to the server is supposed to happen.
Dean Hoover wrote:
Fair enough, Chuck.
I don't know exactly what writes the file, but since we are using the
Lightning add-on from Thunderbird, I would assume that Lightning is doing
the work.
As far as how it used to work, everyone would read from the .ics
calendar on
the old server from Lightning via a web link. Those with the proper
access
were able to write to it for adding/updating/deleting calendar entries.
Don't get me wrong, I appreciate the feedback. It seems that this is a
little more involved than I thought, which is fine. I see there are
open-source alternatives, so I will pursue those.
It's all good. Thanks again.
Dean
On Thu, Sep 15, 2011 at 9:47 AM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:
From: Dean Hoover [mailto:kb7...@gmail.com]
Subject: Re: Using calendar .ics files over Tomcat 5.5
We are not using DAV, just simple iCalendar (.ics) files.
But what _writes_ the files? Unless you have your own servlet to do
this,
or use DAV or a similar file upload mechanism, nothing cause an
update of
data on the server.
It was running on an old Win2k server using an even
older Apache web service before.
Perhaps if you explained more fully how the prior mechanism worked, we
could suggest an alternative for use with Tomcat. So far, we've
really got
nothing to go on.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
