On Fri, May 18, 2012 at 1:09 AM, Oliver-Rainer Wittmann < [email protected]> wrote:
> Hi, > > > On 17.05.2012 03:13, Kay Schenk wrote: > >> On Wed, May 16, 2012 at 1:44 PM, Oliver-Rainer Wittmann< >> [email protected]> wrote: >> >> Hi, >>> >>> On 16.05.2012 21:58, Kay Schenk wrote: >>> >>> >>>> [snip] >>>>>> >>>>> >>>>> >>>>> One of the problems we will run into, esp for Linux (I don't know >>>>> about >>>>> >>>>>> other platforms) is that the user has a appended "pkgfmt" already on >>>>>> the >>>>>> update URL, so in my experimenting, the update call failed because an >>>>>> acceptable package was not found. >>>>>> >>>>>> >>>>> From my point of view this should not be a problem as it seems that >>>>> the >>>>> HTTP server neglects the URL query part in such a "static" case. >>>>> I am not an expert here, please correct me if I am wrong. >>>>> >>>>> >>>> well, I'll try it again...I have several versions to play with...I seem >>>> to >>>> recall I had to manually delete the pkgfmt business and then I got it to >>>> work. >>>> >>>> >>>> I have recently tested on Ubuntu with an old developer snapshot of AOO >>> 3.4. >>> It just worked fine, even with an update URL having the query part. >>> >>> >> OK...I recall I had to take this off and then it did work with getting me >> a >> URL page. >> >> > I am not sure, if we both about the same. > Thus, please let me in more detail describe what I am observing: > For the "static" solution we would have a corresponding HTTP resource (our > XML document) at URL X. I see that the HTTP GET requests made by the update > functionality in AOO 3.4 and OOo 3.3 to URL X?pkgformat=deb are answered by > the HTTP server. The response from the HTTP server contains the requested > HTTP resource - in our case the XML document. > Then the XML document is parsed by the update functionality in AOO 3.4 > resp. OOo 3.3. Two cases needs to be distinguish here: > (1) XML document is in the simple form - only containing XML element > <inst:description> with corresponding childs. > (2) XML document is in the atom feed form > > In case (1) the update functionality checks the following three conditions: > (a) <inst:os> content matches the one of the installed version > (b) <inst:arch> content mathes the one of installed version > (c) <inst:buildid> contant - BuildID of newer version - is greater than > the BuildID of the installed version. > Possible values for <inst:os> and <inst:arch> can be found in [1]. > If the conditions hold further information are read - <inst:version> and > <inst:update> - and the user is presented the information that an update is > available together with the update URL. > If the conditions do not hold - e.g. empty <inst:description> element the > user is presented the information that installed version is up to date. > > In case (2) the update functionality searches for entries which matches > the condition that attribute term of element <category> matches the one of > installed version. Then action as in case (1) are performed on each entry > until an entry matches the above conditions. > > If, I understand your observations correct, you need to remove the query > part from the update URL in order to assure that the update functionality > recieves the XML document. Is this correct? > well this is what I remember...yes. After I did that, I did get the "go to URL" approach to work. I was running 3.3, can't recall what the build number was. > > [1] https://svn.apache.org/repos/**asf/incubator/ooo/trunk/main/** > sal/rtl/source/macro.hxx<https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/sal/rtl/source/macro.hxx> > > >> When I browse to >> http://update36.services.**ope**noffice.org/**<http://openoffice.org/**> >>> ProductUpdateService/check.****Update?pkgformat=deb<http://** >>> update36.services.openoffice.**org/ProductUpdateService/** >>> check.Update?pkgformat=deb<http://update36.services.openoffice.org/ProductUpdateService/check.Update?pkgformat=deb> >>> >**using the FireFox it provides me the content of the XML document. >>> >>> BTW, I have already updated the XML document as you suggested. As I >>> forgot >>> to include an entry for Linux 32bit in my first try you may be hit my >>> first >>> XML document. >>> >>> >>> I'll get back to you on this later today. >>> >>>> >>>> >>>> Ok, thanks. >>> >> >> >> OK, well since I am at 3.4., I can't help much with this without editing >> the XML doc yo have out there I'm afraid, so I will take your word for >> what >> you say works and just hope we can get on with things. >> >> > Yes. When you are testing with a released AOO 3.4 you at least need to > increase the value of <inst:buildid> in the XML document to get the > information from the update functionality that an update is available. > > > >> >>> >>> >>> I think I will make a discussion thread to totally ditch the pkgfmt >>>> business >>>> from Linux update URLs. It would considerably simplify our lives. >>>> >>>> >>>> Do you mean for future versions of AOO? >>> >>> >> yes...this would be best I think. Installing on Linux automatically can be >> tricky if you're not root anyway. No harm in just shuttling folks to a >> page >> to choose something and then do the install in my mind. >> >> > I never tried the automatic installation on Linux. I will hae a look in my > Ubuntu VM which has OOo 3.3 installed. > > > >> >> This may be possible, because this information could also "coded" into >>> the >>> "User-Agent" field of the HTTP GET request. >>> >>> >> I don't get your meaning here. Sorry. ???? >> >> > The HTTP GET request contains information about the installed version > making the request. The needed package format is currently "coded" as the > URL query part. But, it could be also "coded" in the HTTP "User-Agent" > field. How would we do that? > > OK, the next step, which we should deal with very cautiously given my past >> experiment, is to get infra to redirect update36.services.openoffice.** >> org <http://update36.services.openoffice.org> to >> the web server IP address. >> >> > From my point of view we only should redirect the update URL of OOo 3.3 - > namely update36..... If it works fine, we can think of redirecting further > update URLs from former versions. > Right--and that was my thought as well. This is why I started out havign infor redirect update30, which, at it turns out, was a HUGE mistake because it didn't work the same as the future versions -- it did POST calls instead of GET. > My personal opionion is that such redirects are not needed - but this is > only my view. well, who knows. We could do it, and potentially, it would do no harm. > > > It would be better if we could just try this with a very limited set of >> updates for the time being...maybe just 32 bit Linux German, for example, >> and take out the others for a bit and see what happens. >> >> The other thing is since we're still in the midst of the traffic for the >> new release, it would be better to wait at least another week. I know >> you've been after this for a while, and I completely understand, but well, >> results were REALLY disastrous with the update30 re-route -- I kid you >> not. >> Within 2 hours it incapacitated the Apache web server with the bad "post" >> calls -- I mean ALL of it -- all sites, and the redirect had to be backed >> out. I know we use "get" now and not post, but who would know this? >> >> > Yes, we should wait for at least one week to establish the update service > for OOo 3.3. And then only for OOo 3.3 I have a suggestion in the meantime, since I take it we would like some additional "in house" testing. You could post a new thread asking for testers who currently still have a 3.3. version (or maybe they have friends that do), tell them they'll need to do a local redirect -- via local /etc/hosts -- from update36.services.openoffice.org, to the web server IP, and then have them do the "Check Update" and see what happens. I actually tried to convince Windows friends to do this when I was working on this in early spring, but I just couldn't convince them they actually had an /etc/hosts and this would do no harm! :/ Maybe you'll have better luck. > > Maybe infra has like a different server we could use -- with a web server >> running on it, but not the main server. I'll try to find out tomorrow on >> #asinfra or you could get on there and find out. >> >> >> > That is great that you are getting in contact with ASF infra regarding > this issue. Thx. > yes, I promise I will...but probably not until Monday. > > Best regards, Oliver. > OK, thanks for all this. ps. If you figure out a way to do a generic URL redirect for all platforms and variants, let us know. This could be VERY helpful. -- ---------------------------------------------------------------------------------------- MzK "The reports of my death are greatly exaggerated." -- Mark Twain
