incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: [DISCUSS][PROPOSAL] redirection of update services to
Date Thu, 29 Mar 2012 16:34:56 GMT
On Wed, Mar 28, 2012 at 11:35 PM, Oliver-Rainer Wittmann <> wrote:

> Hi,
> On 28.03.2012 18:43, Joe Schaefer wrote:
>> Well I wouldn't say it like that Kay. 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.
>> 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.
> I am not sure about which clients you are talking about.
> If former instances are meant I can share here what I have
> learned during the integration of serf as the new HTTP/WebDAV client
> library in AOO:
> When OOo wants to load a resource (file or folder) via HTTP/HTTPS it sends
> a PROPFIND request in order to find out, if the corresponding server
> "talks" WebDAV. May be the request is sent several times in order to
> workaround an unreliable network. A HEAD request might follow. Then OOo
> sends the GET request (in case of a file) to load it.
> These HTTP requests should be observed on the server providing the update
> service when OOo automatically or the user manually triggers a "check for
> updates".
> Best regards, Oliver.


This is interesting. Can it be applied to the older versions already
installed by users? And, is so, can you supply details, or a "proof of
concept" installation?

Day before yesterday, we  tried to do a test (DNS re-routing) with the
older "" (I don't even know which version
this was the update service for), I am wondering if those *older* clients
were doing something different from what say the newer 3.x versions are.
And yep, there were a LOT of them! This is what caused the web server issue.

I did indeed see all the "POST" errors (disallowed by the webserver) that
Joe is referring to. I did several tests yesterday with my re-routed and things worked pretty well. I'm hoping
I can contact you later today about this and have you do an update via
Windows. I need to track down the web logs from what *I* did yesterday to
see what they reveal.

What I've done now is, instead of just putting the "null" update feed out
there is a feed which points to a "page" URL so folks can chose an update
to install -- currently it's going to the developer page on the wiki.

I will tailor it more to see if I can make it more "generic" (absence of
language and platform), with just a buildid, and see if it still works. I
think an approach like this will be more "friendly" for existing users.

Later ....


"Women and cats will do as they please,
 and men and dogs should relax and get used to the idea."
Robert Heinlein

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message