On Aug 14, 2012, at 12:31 PM, Rob Weir wrote:
> On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher <[email protected]> wrote:
>>
>> On Aug 14, 2012, at 12:09 PM, Oliver-Rainer Wittmann wrote:
>>
>>> Hi,
>>>
>>> Am 14.08.2012 um 20:52 schrieb Dave Fisher <[email protected]>:
>>>
>>>>
>>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>>>
>>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <[email protected]>
>>>>> 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?
>>
>
> 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:
<Directory /projects>
ErrorDocument 404 default
</Directory>
Correct me if I'm wrong but that should make anything in that tree return a
real 404.
And overrides:
ErrorDocument 404 /docs/custom_404.html
Regards,
Dave
>
> Thanks,
>
> -Rob
>
>> Regards,
>> Dave
>>
>>>
>>> Best regards, Oliver.
>>>
>>>
>>
