On Wed, Mar 28, 2012 at 9:43 AM, Joe Schaefer <joe_schae...@yahoo.com>wrote:
> Well I wouldn't say it like that Kay. ok...well, I didn't know how to word it since I didn't exactly understand what you were saying. The cgi area I was trying to experiment with with separate from the DNS change asked for. More below... > The problem > with any update service is the sheer number of clients > out there configured to abuse it. There are a number > of options available, but most of them revolve around > providing an Apache C module to at least cut down on > the redundant traffic before showing it to your script. > > Is it actually a cgi script at this point that you > are trying to service the traffic with, or just a static > file? Right now our webserver is configured to disallow > any attempts to POST data to us, so none of yesterday's > traffic was handled by any of your work in this regard- > it was all interrupted by the server with a "Method Not > Allowed" 4xx response. > What this "service" is, is an XML file that can be processed by OpenOffice clients to inform them that updates are available and what form that update takes. The XML file can then cause actual update installations or, just simple links to a web page (initiating a browser open) where the use can then choose what to install. I don't thinks this qualifies as a "cgi" does it? Maybe I'm not knowledgabel enough about this to answer this question to your satisfaction. > I'd be willing to try experimenting again if in fact > you are trying to service that traffic with a static > file that naturally ignores POST data instead of with a > cgi script. The point is to figure out how to see if > > those misconfigured clients will back-off if given > an expected response. > Hmmm... the clients are not misconfigured, but it could very well be that we need to understand more about how the "backend" configuration --i.e. the XML feed, affects the client, and the response from the update server. Much will depend on what we want the "end" response to be. The simple script that does nothing should have little effect I would think. If we got a bit more adventurous and actually sent the user to a page for updates -- well, I am not sure what the outcome of this would be. I'm still experimenting with my own setup (manual DNS changes), and some responses, etc. I will let you know if I want to try something further. But I definitely don't want to impact the existing Apache web server, so really an alternate location would be best. I'll be back in touch at some point. > > > > >________________________________ > > From: Kay Schenk <kay.sch...@gmail.com> > >To: ooo-dev@incubator.apache.org > >Sent: Wednesday, March 28, 2012 12:32 PM > >Subject: Re: [DISCUSS][PROPOSAL] redirection of update services to > www.openoffice.org > > > > > > > >On 03/23/2012 01:41 AM, Oliver-Rainer Wittmann wrote: > >> Hi, > >> > >> On 22.03.2012 22:35, Kay Schenk wrote: > >>> As we all know, the program update services, the actual update > equipment > >>> and the services they provided have not worked *in a while*, they are > >>> non-responsive. > >>> > >>> 1) Background and Problem > >>> > >>> This would include the following URLS: > >>> > >>> update.services.openoffice.org > >>> update30.services.openoffice.org > >>> update31.services.openoffice.org > >>> update32.services.openoffice.org > >>> update33.services.openoffice.org > >>> update34.services.openoffice.org > >>> update35.services.openoffice.org > >>> update36.services.openoffice.org > >>> > >>> Pings to these don't return. > >>> > >>> These are referenced in the program in a user's "install > >>> location"/program/"version init file" > >>> > >>> the name of "version init file" varies by installation platform. > >>> > >>> Each of the update services above typically included a check for update > >>> area with the name-- > >>> .../ProductUpdateService/check.Update > >>> > >>> A complete URL example (referenced in the version file): > >>> update36.services.openoffice.org/ProductUpdateService/check.Update(<http://update36.services.openoffice.org/ProductUpdateService/check.Update%28> > ?"optional > >>> params") > >>> > >>> "check.Update" would normally be an xml feed which would include, as > part > >>> of its entry for each platform, and language version, a pointer to > another > >>> URL which would actually have and install the update for the given > system. > >>> See details and notes on this at: > >>> > >>> http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol > >>> > >>> > >>> 2) Proposed Solution > >>> Several participants on this list have been researching the "Update > >>> Notification Protocol" and creating "snippets" of the feeds (both > simple > >>> and atom) for very limited one platform situations. However, the > creation > >>> of a complete feed for all platforms has not been done ... yet. More > >>> research and development time is needed for this. > >>> > >>> Meanwhile, many current OOo users who either use the "check for > updates" > >>> feature of their program or have updates "automatically enabled" > continue > >>> to be frustrated with the unavailability of the update service. > >>> > >>> Although we still have not solved the problem of *HOW* to re-create the > >>> complete service (feed), we can create a "null" placeholder feed for > all > >>> services mentioned in 1) that would return the message: > >>> > >>> "OpenOffice x.x is up to date" > >>> > >>> Essentially, all update services mentioned above would be redirected an > >>> appropriate area on the current web server, www.openoffice.org, which > would > >>> return "no" information in placeholder feeds for each update service. > >>> > >>> > >>> Thoughts? > >>> > >>> > >>> > >> > >> First, Thx Kay for the summary. > >> > >> From my side a +1 to this proposal. > >> From my point of view the "no" information placeholder is a temporary > solution to fullfill the purpose to avoid the frustation of our users of > former versions. > >> It should be working until our AOO 3.4 release (may be 1 or 2 weeks > longer). > >> > >> When AOO 3.4 is out my expectation is that we provide a > platform-independent and language-independent "check.Update" information > which provides a download website which the user can open in her/his > browser from the office's update service dialog. On this website we can > state that AOO 3.4 is out and that the user should have a look, if a > corresponding package for her/his platform and language is available for > download and installation. > >> > >> Best regards, Oliver. > > > >After an "experiment" with just redirecting " > update.services.openoffice.org", an older update service which I thought > would have little impact, to www.openoffice.org yesterday, I am > rescinding this suggestion. Yes, we need to port even a "simple" reply like > this somewhere, but it's clear it can't be via the web server due to load > considerations. > > > > > >Suggestions on an alternate setup/location? > > > >-- > ------------------------------------------------------------------------ > >MzK > > > >"Women and cats will do as they please, > >and men and dogs should relax and get used to the idea." > > -- Robert Heinlein > > > > > > > > > -- ---------------------------------------------------------------------------------------- MzK "Women and cats will do as they please, and men and dogs should relax and get used to the idea." -- Robert Heinlein
