Is there what could be considered a "default" mimetype?
I've seen "unknown/unknown" and "application/binary". But is there a default to revert to when no other MIME type is found?
The least specific official MIME type is application/octet-stream. Without any additional information, it says "here is a bunch of bytes, hopefully there is an application over on your end which knows what to do with them". Sometimes there is a file name which helps convey to the recipient what to do with the data.
"unknown" doesn't really add anything over this, except to confuse clients who don't support random unofficial MIME types. Ditto for application/binary; it's just a non-standard way of restating "octet-stream".
This is the answer to "What can I put in the Content-Type: header if I can't find an existing content type which adequately describes my data?" which is how I have interpreted this question. The proposed duplicate Unknown file type MIME? has a lengthy answer which discusses "How is my data interpreted if I don't put a valid Content-Type: header?" specifically in an HTTP context; the answer to that is protocol-specific (in email, for example, the default implied Content-Type: for MIME body parts which do not contain this header is text/plain; charset="us-ascii").
Related
What is the way to configure/override how certain MIME types are handled?
For example, with the default configuration a python file (.py) is served with Content-disposition": attachment which opens a file save dialog rather than displaying inline plain text in the browser.
I've identified one possible approach:
#py {
path *.py
}
header #py Content-Type text/plain
While this works, it looks more of a hack rather than adding/modifying a mime type, given that it's simply setting a header based on a substring match. Is this the only possible approach?
What defines that a specific MIME type should be served inline or have "Content-disposition": attachment? Does caddy expose a straightforward way to configure how MIME types are handled?
The correct mime type for .py files is application/x-python-code or text/x-python. How can I configure caddy to treat these types as inline plain text, and not add the Content-disposition": attachment header? Forcing text/plain works as a workaround, but I am assuming there is a cleaner way to do it.
What's the difference between application and text in media types and when do they use what?
For example there is text/html but on the other hand it's application/json.
Is this a historical thing?
This is described on the MIME types page of the mozilla documentation.
application refers to any kind of binary data while text is theoretically human readable.
type/subtype
The structure of a MIME type is very simple; it consists of a type and
a subtype, two strings, separated by a '/'. No space is allowed. The
type represents the category and can be a discrete or a multipart
type. The subtype is specific to each type.
A MIME type is case-insensitive but traditionally is written all in lower case.
Further down the page you can find a table containing the discrete types:
Type Description
text Represents any document that contains text and is theoretically human readable
image Represents any kind of images. Videos are not included, though animated images (like animated gif) are described with an image type.
audio Represents any kind of audio files
video Represents any kind of video files
application Represents any kind of binary data.
To answer your question about JSON, while you'll frequently come across JSON that is human readable it's primarily used for containing data and isn't necessarily intended to simply be read. Meanwhile a machine can always easily convert the data from JSON into an object (assuming the JSON is correctly formatted).
Raw images are produced by cameras, scanners, etc. and typically give you more post-processing flexibility than JPEG images.
If I’m serving this kind of file from my web server, which media type (a.k.a. MIME type) should I use? I’m specifically interested in the CR2 files produced by recent Canon cameras, but answers could also address Adobe’s Digital Negative (DNG) format or raw files from other manufacturers’ cameras. (I didn’t see anything relevant in this list from the IANA.)
According to this XML file from the (defunct?) GNOME RAW Thumbnailer project, the MIME type for raw images in general is image/x-dcraw. Listed by their file extensions, here are the other file types mentioned in that file:
ARW: image/x-sony-arw
CR2: image/x-canon-cr2
CRW: image/x-canon-crw
DCR: image/x-kodak-dcr
DNG: image/x-adobe-dng
ERF: image/x-epson-erf
K25: image/x-kodak-k25
KDC: image/x-kodak-kdc
MRW: image/x-minolta-mrw
NEF: image/x-nikon-nef
ORF: image/x-olympus-orf
PEF: image/x-pentax-pef
RAF: image/x-fuji-raf
RAW: image/x-panasonic-raw
SR2: image/x-sony-sr2
SRF: image/x-sony-srf
X3F: image/x-sigma-x3f
It might be too late for the author of the question, but might be helpful for others struggling with the same problem.
For .CR2 it is image/x-dcraw.
For .DNG it is image/x-adobe-dng
Using the convention of Gnome raw thumbnailer might be an option but MIME is assigned by IANA based on reference standards and/or requests of the vendors, so is certainly a non-uffical way even though these are the MIME the vendors are using. The list of official IANA MIME can be found here. All the other list are actually unofficialial. Also, the Wikipedia list is often not updated.
If the MIME is not present in the list you could extract it using tools such exiftool and looking for MIME Type.
I would also consider to use application/octet-stream which is an official MIME type and is used for unknown types of binary data as explained in RFC 2046, at least the application will know that it is a binary file.
If you don't like this solution or a MIME used by the vendors and need to disambiguate from multiple RAW image files, I would follow the convention used for other proprietary image types in the standard: image/vnd.<manufacturer>.<filename extension> for instance for NEF by Nikon corporation and .mrv for Minolta:
image/vnd.nikon.nef
image/vnd.minolta.mrw
But of course this is a pure speculation and will be not recognized by other application.
Swagger by default supports application/json as Content type. And if I want to add other Content types then "produces" or "consumes" fields needs to updated in the swagger JSON file. Client may send any type of Data. Is there a way to support any Content type (remove the validation for Content type or regex like *) in swagger
As far as I have worked on go-swagger, you will have to mention in the swagger-spec file and generate the code again in order to do that. You can use / to describe that the endpoint can generate all type of data. But you can not modify it after you have generated the code using go-swagger.
You can directly modify the generated files but it's not recommended.
I am writing a simple migration tool in which I have to migrate gmail mailboxes to some other email provider. I am confused about raw string returned from gmail api.
In Google document, it says:
"raw": Returns the entire email message content in the raw field as a URL-safe base64 encoded string and the payload field is not used. This includes the identifiers, labels, metadata, MIME structure, and small body parts (typically less than 2KB).
So this means "raw" returns only small body parts less than 2kb and if the body parts are more than 2KB, there will be a problem. I have checked with some dummy emails containing email body(including inline attachments) more than 2KB, and it still works. It still returns the complete body without any problem. Sorry,if I missed something, please clear my confusion. If "raw" is working fine for all email body sizes , I will be using this approach in my project instead of "full" query parameter.
best regards,
messages.get(format=RAW) returns the entire email always. That document: https://developers.google.com/gmail/api/v1/reference/users/messages/get is incorrect and needs to be fixed.