incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <orwittm...@googlemail.com>
Subject Re: Info about the update protocol
Date Fri, 30 Mar 2012 07:41:11 GMT
Hi,

further results of network traffic - see below

On 30.03.2012 08:51, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 30.03.2012 08:26, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> On 29.03.2012 19:15, Kay Schenk wrote:
>>> On Thu, Mar 29, 2012 at 2:23 AM, Oliver-Rainer Wittmann<
>>> orwittmann@googlemail.com> wrote:
>>>
>>>> Hi Joe,
>>>>
>>>>
>>>> On 29.03.2012 03:31, Joe Schaefer wrote:
>>>>
>>>>> Look I'm pretty serious about the situation as
>>>>> it stands. If someone can just give me a little
>>>>> pointer to where the update client is implemented
>>>>> in the svn tree that would be great.
>>>>>
>>>>
>>>> You will find the main stuff in /main/extensions/source/**update/check.
>>>> In updateprotokoll.cxx you will find function<checkForUpdates(..)>.
>>>> Please have also a look at [1], esp. [2].
>>>>
>>>> Our UCB (Universal Content Broker) is used to get the update information
>>>> (an response in XML format) via the URL which is given in the<version.ini>
>>>> resp.<versionrc> file. The URL is found at item<UpdateURL> in
this file.
>>>>
>>>> I have have checked what kind of HTTP requests are triggered by our "Check
>>>> for Updates" function. It is a GET request. It should be a single one.
>>>>
>>>
>>> a ha! So...maybe the business we saw on Tuesday was from an older
>>> implementation that used "POST" instead of "GET". I was going to spend
>>> some time today looking into this Oliver. So --THANK YOU!
>>>
>>> OK, next question... do you or anyone else happen to have a mapping between
>>> update host names and versions to which they apply?
>>>
>>> We redirected "update.services.openoffice.org" which MAY be the URL for
>>> older clients that used "POST" instead of "GET". I don't know version of
>>> OOo this would have been configured for.
>>>
>>> Should we assume that all the update3x.service.openoffice.org
>>>
>>> apply to OpenOffice.org 3.x clients which are probably implementing the
>>> corrected protocol -- GET vs POST?
>>>
>>> I'm happy we're making progress on this!
>>>
>>> ps. I also found update23.services.openoffice.org and
>>> update24.openoffice.org as valid DNS entries which we definitely NOT
>>> re-rotue probably due to the same issues.
>>>
>>
>> Currently, I have
>> OOo 2.2, OOo 3.1, OOo 3.1.1 and OOo 3.3 installed.
>> The URLs are according <version.ini> resp. <versionrc>:
>> - OOo 2.2:
>> http://update.services.openoffice.org/ProductUpdateService/check.Update
>> - OOo 3.1:
>> http://update32.services.openoffice.org/ProductUpdateService/check.Update
>> - OOo 3.1.1:
>> http://update32.services.openoffice.org/ProductUpdateService/check.Update
>> - OOo 3.3:
>> http://update36.services.openoffice.org/ProductUpdateService/check.Update
>>
>> I have installationsets for OOo 3.0, OOo 3.0.1, OOo 3.2 and OOo 3.2.1 on my
>> machine. I will install them and check the <version.ini> resp. <versionrc>.
>> I will have a look on the network traffic to figure out which HTTP requests are
>> sent.
>>
>
> I have already checked the network traffic for OOo 2.2 after I had change the
> <UpdateURL> to http://www.openoffice.org/ProductUpdateService/check.Update:
> OOo 2.2 sends a GET request followed by a OPTIONS request.
>
> Further reports will follow.

Network traffic of different OOo versions after updating the <UpdateURL> to 
http://www.openoffice.org/ProductUpdateService/check.Update:
- OOo 3.0 (original <UpdateURL> == update30....) sends a GET request (200 OK 
reply) followed by three PROPFIND requests (405 Method not allowed replies) 
followed by a HEAD request
- OOo 3.0.1 (original <UpdateURL> == update30....) sends a GET request (200 OK 
reply) followed by a PROPFIND request (405 Method not allowed reply)
- OOo 3.1 - the same as OOo 3.0.1
- OOo 3.1.1 - the same as OOo 3.0.1
- OOo 3.2 (original <UpdateURL> == update34....) - the same as OOo 3.0.1
- OOo 3.2.1 (original <UpdateURL> == update35....) - the same as OOo 3.0.1
- OOo 3.3 sends a GET request (200 OK reply)
- OOo 3.4 Beta (original <UpdateURL> == update38....) - the same as OOo 3.3


Best regards, Oliver.

>
> BTW, does the server logs track the <User-Agent> HTTP header field content of
> the HTTP requests?
> It should contain all the necessary information to identify the OOo
> installation. For my OOo 2.2 this HTTP header field contains "OpenOffice.org 2.2
> (680m14(Build:9134); Windows; x86; BundledLanguages=en-US"
>
>
> Best regards, Oliver.
>
>>>
>>> As I only looked at the current code this might not be the same for former
>>>> OpenOffice.org instances.
>>>>
>>>> [1] http://wiki.services.**openoffice.org/wiki/Update_**
>>>> Notification_Protocol<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol>
>>>>
>>>>
>>>> [2] http://wiki.services.**openoffice.org/wiki/Update_**
>>>> Notification_Protocol#A_**glance_on_the_code_for_the_**
>>>> Apache_OpenOffice_3.4_release<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol#A_glance_on_the_code_for_the_Apache_OpenOffice_3.4_release>
>>>>
>>>>
>>>>
>>>> If you need further information etc., do not hesitate to ask - I will give
>>>> my best to support you.
>>>>
>>>>
>>>> Best regards, Oliver.
>>>>
>>>>
>>>>
>>>>> There is work to do here to integrate the update
>>>>> service into Apache's mirror infrastructure, and
>>>>> the division of labor between what the project can
>>>>> do and what infra needs to do isn't clear at all
>>>>> right now. It'd sure be nice to have a solution
>>>>> implemented prior to AOO 3.4's release, which I'm
>>>>> trying to accommodate but my time is limited.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ______________________________**__
>>>>>> From: Joe Schaefer<joe_schaefer@yahoo.**com<joe_schaefer@yahoo.com>>
>>>>>> To: "ooo-dev@incubator.apache.org"**<ooo-dev@incubator.apache.org>
>>>>>> Sent: Wednesday, March 28, 2012 10:33 AM
>>>>>> Subject: Info about the update protocol
>>>>>>
>>>>>>
>>>>>> Looking at the most recent experiment with
>>>>>> updates.services.apache.org does not inspire
>>>>>> my confidence that this service was well-thought-out
>>>>>> because it shouldn't be possible for j random user
>>>>>> to configure it to poll continuously for updates.
>>>>>> I can only hope that future variants of the service
>>>>>> were better designed from a network utility standpoint.
>>>>>>
>>>>>>
>>>>>> In any case is there any reason to suspect that throwing
>>>>>> this traffic at a protocol-compliant script will be able to
>>>>>> tell clients to back off? Where is the update protocol
>>>>>> documented in case infra needs to write a more scalable
>>>>>> implementation of it as an Apache C module? Any tips,
>>>>>> especially a willingness by volunteers to resolve outstanding
>>>>>> scaling issues, will be appreciated by both infra and your
>>>>>> users of the service.
>>>>>>
>>>>>>
>>>>>> TIA
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>

Mime
View raw message