2013/8/19 Roberto Galoppini <roberto.galopp...@gmail.com> > > > > 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<http://heanet.dl.sourceforge.net/project/aoo-extensions/17102/1/dict-en.oxtContent-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. >
Our mirrors have been updated with an extra mime type definition for extension files (*.oxt). Everything should be ok by now. Roberto > > 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 >> >> >
