You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Joe Schaefer <jo...@yahoo.com> on 2012/03/28 16:33:29 UTC
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
Re: Info about the update protocol
Posted by Kay Schenk <ka...@gmail.com>.
On 03/30/2012 12:41 AM, Oliver-Rainer Wittmann wrote:
> 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.
Interesting and thanks...OK, you're routing everything to my original
"do nothing" XML. I am also continuing to experiment with local file
setup that might lead folks to the snapshot DL page. More work on this
though. With local file URL I need to pass in more params I think.
Your other message, re
"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."
hmmmm...OK. No idea about what was causing the POST request which is
*clearly* in the error logs. Maybe soem very old versions which happened
to have update.services.openoffice.org as the update URL but didn't work
the same at all.
I'm thinking if we do redirects, we need to ditch this one completely!
Maybe we can come to a consensus early next week (Tues?) on all this.
I think we'd be safe redirecting "update3x.services.openoffice.org" but not
update.services.openoffice.org.
Thanks again for all your work on this!
>
>>
>> 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<jo...@yahoo.com>>
>>>>>>> To: "ooo-dev@incubator.apache.org"**<oo...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
Re: Info about the update protocol
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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<jo...@yahoo.com>>
>>>>>> To: "ooo-dev@incubator.apache.org"**<oo...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
Re: Info about the update protocol
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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.
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<jo...@yahoo.com>>
>>>>> To: "ooo-dev@incubator.apache.org"**<oo...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
Re: Info about the update protocol
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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.
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<jo...@yahoo.com>>
>>>> To: "ooo-dev@incubator.apache.org"**<oo...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
Re: Info about the update protocol
Posted by Kay Schenk <ka...@gmail.com>.
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.
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 <jo...@yahoo.com>>
>>> To: "ooo-dev@incubator.apache.org"**<oo...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
--
----------------------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
--
Robert Heinlein
Re: Info about the update protocol
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
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.
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
[2]
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<jo...@yahoo.com>
>> To: "ooo-dev@incubator.apache.org"<oo...@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
>>
>>
>>
>>
>>
>>
Re: Info about the update protocol
Posted by Joe Schaefer <jo...@yahoo.com>.
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.
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 <jo...@yahoo.com>
>To: "ooo-dev@incubator.apache.org" <oo...@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
>
>
>
>
>
>