[Building Sakai] Resource content type and version 1.5 PDFs

[Joshua Swink]

I think this would be a good change for Sakai. I doubt it would be
worthwhile to make the order configurable.

Josh

On Mon, Apr 26, 2010 at 11:33 AM, Matthew Jones <jonespm at umich.edu> wrote:
> 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.
> -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"
>
>