Project

General

Profile

Bug #1012

Need to allow metacat admin to set default mime type

Added by Chris Jones over 16 years ago. Updated over 16 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
03/18/2003
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
1012

Description

the metacat servlet does it's best to determine the mime type of the data entity
being served. However, entities that are stored on the local filesystem with a
name in the form of prefix.1.1 don't give the servlet any clues as to the mime
type based on the file ending. As a last resort, metacat sets the default mime
type to application/octet-stream, which results in a 'download' dialog over the
web, rather than attempting to render the data file (even text/plain).

This may be desired, but some metacat admins may want text files to render
preferentially, or other file types. It seems that there needs to be a mapping
between eml dataFormat fields that hold the equivalent of a mime type (or it's
surrogate), and the true mime type name used to set the HTTP CONTENT_TYPE
header. The mapping shouldn't be schema dependent, rather, when a schema is
registered in metacat, the mapping should be registered as well.


Related issues

Is duplicate of Metacat - Bug #1013: Need to allow metacat admin to set default mime typeResolved03/18/2003

History

#1 Updated by Jing Tao over 16 years ago

  • Bug 1013 has been marked as a duplicate of this bug. ***

#2 Updated by Matt Jones over 16 years ago

This is a good feature. For EML 2.0.0, we should be able to get the mime type
from the eml-physical module, either directly or by inference. Here are the
common cases I see:

dataFormat/textFormat/simpleDelimited > text/plain (does text/csv exist?)
dataFormat/textFormat/complex > text/plain
dataFormat/externallyDefinedFormat > application/octet-stream, unless
formatName is a mimeType, in which
case use formatName
dataFormat/binaryRasterFormat > application/octet-stream, unless
there is a better mime type for
BIP and BIL

If none of these work, then the following can be checked as well to see if they
contain a mime type that can be returned:

dataset/otherEntity/entityType

Finally, one might be able to make a reasonable guess based on what type of
entity is being returned:

dataset/dataTable
dataset/spatialRaster
dataset/spatialVector
dataset/storedProcedure
dataset/view

but this last one seems unreliable becuase several mime types are legitimate for
each of those entity types.

#3 Updated by Jing Tao over 16 years ago

When usr asks for a data file, metacat will take a look on xml_relation table
to find a metadata document which describes the datafile.

If the metadata doc is eml beta6, the related physical document will be found
and the fromat value in this document will be read. From format value, Metacat
will guess the mine type. Fro example, if it is text, Mine type will be
text/plain. If it is gif, the mine type will be image/gif. If the mine type
couldn't be figured out, the default mine type value(user can specify it in
build file) will be applied.

If it is a eml2 document, the above rules will be applied to Mine type. If
still counldn't figure out, the default value will be applied.

#4 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 1012

Also available in: Atom PDF