openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roberto Galoppini <roberto.galopp...@gmail.com>
Subject Re: Usability: dictionary updates and profile migration
Date Mon, 19 Aug 2013 20:03:51 GMT
2013/8/19 sebb <sebbaz@gmail.com>

> On 19 August 2013 16:39, Rob Weir <robweir@apache.org> wrote:
> > On Mon, Aug 19, 2013 at 11:16 AM, Andrea Pescetti <pescetti@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-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

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