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. > -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
