Well I wouldn't say it like that Kay. 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. 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. >________________________________ > 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(?"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 > > > >
