[Building Sakai] Resource content type and version 1.5 PDFs

[Matthew Jones]

This would make more sense. Since Sakai trusts the browser mime first, if
this is incorrect then the type will be incorrect. There is this 3 year old
bug in firefox (ubuntu) which looks like it's still unfixed where pdf's are
sent with seemingly random mime types. Some reports say "*application/binary"
*some say "*text/html"* others say *"application/x-download"*. Doesn't seem
to be any specific fix other than to use a different browser.

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/84880

Part of the Sakai fix I was going to work on was to put content type
detection first, which "should" be the most reliable, then trust the browser
(which as we see is isn't very accurate), then default to extension. However
I was wondering if it would be worth it to spend extra time to try to make
this ordering user definable.

<https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/84880>-Matthew

On Mon, Apr 26, 2010 at 2:02 PM, Joshua Swink <jswink at ucmerced.edu> wrote:

> After more testing, I've ruled out the PDF version as the problem.
> It's affecting some of our Firefox users. It is proving difficult to
> pinpoint the difference in the user environments that is triggering
> the problem - we have ruled out operating system and extensions.
>
> I turned on DEBUG.org.sakaiproject.content logging but there was no
> difference between a successfully identified upload and a failed one.
>
> Josh
>
> On Thu, Apr 22, 2010 at 10:39 AM, Matthew Jones <jonespm at umich.edu> wrote:
> > As mentioned on KNL-101 the current mime detection scheme in sakai is:
> > Browser (if supplied), File Extension (if exists), Unknown (last resort),
> > So for some reason the browser must be not be providing a mime type for
> > Sakai. Then it's still unable to recognize it based on the extension
> either
> > because this extension file is missing or because of some other bug?
> > The default lookup file for content type extensions for 2.6 is in
> >
> config/localization/bundles/src/bundle/org/sakaiproject/localization/bundle/content_type/content_type_extensions.properties)
> > I had proposed in this SAK a few methods of fixing this process;.
> Allowing
> > the detection order to be changed (trusting extension over browser?) and
> > also possibly detecting the mime type based on a library that does
> detection
> > from the actual file contents. However I never got any feedback on the
> list
> > or SAK, and it seems like a pretty big change to make without any
> > discussion, so it's kind of just hung out there. It also might have
> needed
> > an internal api change as mentioned as fixTypeAndId doesn't get passed
> the
> > file contents to examine.
> > -Matthew
> > On Thu, Apr 22, 2010 at 1:20 PM, Joshua Swink <jswink at ucmerced.edu>
> wrote:
> >>
> >> Recently we've had some version 1.5 PDFs uploaded to resources, and
> >> they're not recognized by Sakai. They are "unknown". Their filenames
> >> end in ".pdf".
> >>
> >> Two questions. First, can we update our server's type recognition to
> >> identify these files correctly? Second, shouldn't it be picking up on
> >> the ".pdf" extension, even if the internal content of the file may not
> >> be recognized?
> >>
> >> Josh
> >> _______________________________________________
> >> sakai-dev mailing list
> >> sakai-dev at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >>
> >> TO UNSUBSCRIBE: send email to
> >> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> >> "unsubscribe"
> >
> >
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100426/7c5cecc3/attachment.html