On Aug 14, 2012, at 12:42 PM, Dave Fisher wrote: > > On Aug 14, 2012, at 12:31 PM, Rob Weir wrote: > >> On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher wrote: >>> >>> On Aug 14, 2012, at 12:09 PM, Oliver-Rainer Wittmann wrote: >>> >>>> Hi, >>>> >>>> Am 14.08.2012 um 20:52 schrieb Dave Fisher : >>>> >>>>> >>>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote: >>>>> >>>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher wrote: >>>>>>> >>>>>>> On Aug 5, 2012, at 11:13 AM, Andrea Pescetti wrote: >>>>>>> >>>>>>>> On 03/08/2012 Rob Weir wrote: >>>>>>>>> On Fri, Aug 3, 2012 at 6:13 AM, Oliver-Rainer Wittmann >>>>>>>>> wrote: >>>>>>>>>> I am planning to give a talk on ApacheCon EU about >>>>>>>>>> the update function in AOO and the Update Service. In this talk I will give >>>>>>>>>> a deep insight in its purpose and functionality which should be enough input >>>>>>>>>> for a corresponding volunteer to create a "real" web service for our Update >>>>>>>>>> Service. ... >>>>>>>>> The question is: how dynamic does it need to be? It is not like the >>>>>>>>> upgrade options change minute by minute. These change slowly, at the >>>>>>>>> pace of our release cycle, so every few months. >>>>>>>> >>>>>>>> Yes, and traffic is a key factor here. With potentially hundreds of millions of clients hitting the servers, the biggest problem is not re-implementing the update service as a web service, but serving it efficiently. And indeed I agree that staticizing the results somehow would be good to do, since we have a relatively low number of possible answers with respect to the number of requests. >>>>>>> >>>>>>> Oliver requested removal of update32 from DNS on INFRA-5112 and now Infra is requesting PPMC agreement. >>>>>>> >>>>>>> Is now a time to discuss cleaning up all of the staroffice urls here: >>>>>>> >>>>>>> update.services CNAME sd-web4.staroffice.de. >>>>>>> update23.services CNAME sd-web2.staroffice.de. >>>>>>> update24.services CNAME sd-web2.staroffice.de. >>>>>>> update30.services CNAME sd-web2.staroffice.de. >>>>>>> update31.services CNAME sd-web2.staroffice.de. >>>>>>> update32.services CNAME www.openoffice.org. >>>>>>> update33.services CNAME sd-web2.staroffice.de. >>>>>>> update34.services CNAME www.openoffice.org. >>>>>>> update35.services CNAME www.openoffice.org. >>>>>>> update36.services CNAME www.openoffice.org. >>>>>>> update38.services CNAME www.openoffice.org. >>>>>>> >>>>>>> update32 is the proposed change in the JIRA issue. >>>>>>> >>>>>>> update33 is the added removal. >>>>>>> >>>>>>> What about update, update23, update24, update30, update31? >>>>>>> >>>>>>> Should we do anything now as well? >>>>>>> >>>>>> >>>>>> I suppose returning errors from *.openoffice.org is no worse than >>>>>> returning errors from *.staroffice.de. And if we do that we can >>>>>> handle these URL's more gracefully in the future if we want to. >>>>> >>>>> It might be nicer to return a 404 rather than timing out on a non-responsive ip address. >>>>> >>>>> Oliver or Kay will need to confirm what will happen. >>>> >>>> I would like to see a 404 for all currently unused updateX*.services URLs. >>>> The former OOo versions which would get in contact with these URLs should handle such replies. >>> >>> The following are current in ooo-site/trunk/content/projects/. >>> >>> update: >>> ProductUpdateService aoo341 >>> >>> update30: >>> ProductUpdateService >>> >>> update34: >>> ProductUpdateService >>> >>> update35: >>> ProductUpdateService >>> >>> update36: >>> ProductUpdateService >>> >>> update38: >>> ProductUpdateService >>> >>> (1) Are update/ProductUpdateSerice and update30/ProductUpdateService ready? The DNS is now done. ooo-site may be changed as needed. >>> >> >> They can be created quickly, based on available time of volunteers. >> But if we have Infra now ready to act on the redirection now, let's >> take advantage of that now, while we have that opportunity. >> >>> (2) Currently all 404s on openoffice.org go here: >>> >>> ErrorDocument 404 /docs/custom_404.html >>> >>> Is that acceptable? Or must we use a real 404 response? >>> >> >> Please redirect them to where they would actually live if we wanted to >> go live with then. e.g., the appropriate directory under >> ooo-site/content/projects/updateXX >> >> In other words, treat them analogously to how we treat the others. >> That way they will indeed give 404's now and then we can update then >> for real without requiring intervention from Infra. > > These urls get rewritten by this default rule: > > # fallback for proj.openoffice.org/... to openoffice.org/projects/proj/... > RewriteCond ${lowercase:%{HTTP_HOST}} ^(?!www)(\w+)(?:\.\w+)?\.openoffice\.org$ > RewriteRule ^(.*)$ ${lowercase:%{HTTP_HOST}}$1 [C] > RewriteRule ^(\w+)(?:\.\w+)?\.openoffice\.org/(.*) http://www.openoffice.org/projects/$1/$2 [NE,L] > > We should probably add: > > > ErrorDocument 404 default > > > Correct me if I'm wrong but that should make anything in that tree return a real 404. Done and tested. [1] is updated. Regards, Dave https://cwiki.apache.org/confluence/display/OOOUSERS/Open+Infrastructure+Requests > > And overrides: > > ErrorDocument 404 /docs/custom_404.html > > > Regards, > Dave > > > >> >> Thanks, >> >> -Rob >> >>> Regards, >>> Dave >>> >>>> >>>> Best regards, Oliver. >>>> >>>> >>> >