2013/8/19 sebb <seb...@gmail.com> > On 19 August 2013 16:39, Rob Weir <robw...@apache.org> wrote: > > On Mon, Aug 19, 2013 at 11:16 AM, Andrea Pescetti <pesce...@apache.org> > wrote: > >> Rob Weir wrote: > >>> > >>> On Thu, Aug 8, 2013 at 3:15 AM, Andrea Pescetti wrote: > >>>> > >>>> Not seeing comments, I'll publish the updated dictionary in a couple > of > >>>> days. In the end this is not breaking anything, it just produces a > Fatal > >>>> Error (that is actually not fatal, and solved by simply restarting > >>>> OpenOffice) during profile migration. ... > >>> > >>> I don't know if it is related, but we're starting to get a few reports > >>> from confused users on Facebook. It sounds like they are getting > >>> dictionary upgrade notifications but are then lost when trying to > >>> download/install the update. It is coming down as a ZIP file rather > >>> than an OXT. > >> > >> > >> This is a known problem with Internet Explorer (unrelated to this > specific > >> extension): at times, IE tries to be smart and "fixes" the filename > >> extension into ZIP rather than OXT as you correctly observed. I don't > have > >> more precise information, but this has happened for years and the common > >> advice given on lists is "use another browser" (obviously, capable > users can > >> rename the file as OXT). > >> > > > > If I.E. is suggesting a ZIP content type then this means they've > > resorted to content sniffing and found the ZIP magic number in the > > file header. Usually a browser only resorts to this if every other > > attempt to determine the content type has failed, e.g., HTTP response > > headers, file name, etc. This is something that should be fixable. > > The request uses a lot of redirects; the last two respond as follows > (some headers dropped): > > HTTP/1.1 302 Found > Content-Disposition: attachment; filename="dict-en.oxt" > Location: > http://heanet.dl.sourceforge.net/project/aoo-extensions/17102/1/dict-en.oxt > Content-Type: text/html > Content-Length: 0 > Server: lighttpd/1.4.26 > > > HTTP/1.1 200 OK > Server: Apache/2.2.14 > Accept-Ranges: bytes > Content-Length: 6529865 > Content-Type: application/octet-stream > > I did an experiment with IE 8 - it downloads as .zip from the > SourceForge, but downloads OK from a copy on people.apache.org. > > The relevant response headers from people.a.o are: > > HTTP/1.1 200 OK > Server: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.1e DAV/2 > Accept-Ranges: bytes > Content-Length: 6529865 > Content-Type: application/vnd.openofficeorg.extension > > So it might be sufficient to ensure that the correct content-type is > returned. > > I think this will need to be done by SourceForge on all their systems. >
Our SiteOps are investigating the issue, will keep you posted. Roberto > > > -Rob > > > > > >> > >> Regards, > >> Andrea. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
