Well no self-respecting web programmer would have the client loop over and over until it receives a proper xml response from the server, yet that appears to be the case here, so I'm charitably suggesting that the clients aren't properly configured instead of suggesting there's a bug in the software. In any case we need to be realistic about the impact of such traffic if we ever hope to expose the service to every user past and present- there might be times when us server admins need to move/interrupt that traffic for various reasons, and not having the flexibility to do so without serious implications to our infra is a problem. If there's somethingto fix in the software in some HTTP status-code aware way, let's do that, so at least wecan avoid carrying thisproblem thru to new/upgraded
users. FWIW the request in question is POST /ProductUpdateService/check.Update Host: update.services.openoffice.org which if we pointed it at the main webserver again would redirect to POST /projects/update/ProductUpdateService/check.Update Host: www.openoffice.org which maps to content/projects/update/ProductUpdateService/check.Update in your svn tree, which is just a basic XML file, not a cgi script. For testing purposes I'm comfortable working with you Kay on #asfinfra (freenode) to deal with the traffic load again should you wish to pursue further testing on the main webserver. After all the server exists to support Apache projects and their use cases, not simply to provide a stable web-serving platform, so this use case is in scope provided we have sufficient coordination (#asfinfra) to deal with the traffic in real-time. >________________________________ > >From: Kay Schenk <kay.sch...@gmail.com> >To: ooo-dev@incubator.apache.org; Joe Schaefer <joe_schae...@yahoo.com> >Sent: Wednesday, March 28, 2012 1:25 PM >Subject: Re: [DISCUSS][PROPOSAL] redirection of update services to >www.openoffice.org > > > > > >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(?"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 > > > > >
