When working with PDFs, I've run across the MIME types application/pdf and application/x-pdf among others.
Is there a difference between these two types, and if so what is it? Is one preferred over the other?
I'm working on a web app which must deliver huge amounts of PDFs and I want to do it the correct way, if there is one.
This question is related to
pdf
http-headers
content-type
mime
From Wikipedia Media type,
A media type is composed of a type, a subtype, and optional parameters. As an example, an HTML file might be designated text/html; charset=UTF-8.
Media type consists of top-level type name and sub-type name, which is further structured into so-called "trees".
top-level type name / subtype name [ ; parameters ]
top-level type name / [ tree. ] subtype name [ +suffix ] [ ; parameters ]
All media types should be registered using the IANA registration procedures. Currently the following trees are created: standard, vendor, personal or vanity, unregistered x.
Standard:
Media types in the standards tree do not use any tree facet (prefix).
type / media type name [+suffix]
Examples: "application/xhtml+xml", "image/png"
Vendor:
Vendor tree is used for media types associated with publicly available products. It uses
vnd.facet.
type / vnd. media type name [+suffix] - used in the case of well-known producer
type / vnd. producer's name followed by media type name [+suffix] - producer's name must be approved by IANA
type / vnd. producer's name followed by product's name [+suffix] - producer's name must be approved by IANA
Personal or Vanity tree:
Personal or Vanity tree includes media types created experimentally or as part of products that are not distributed commercially. It uses
prs.facet.
type / prs. media type name [+suffix]
Unregistered x. tree:
The "x." tree may be used for media types intended exclusively for use in private, local environments and only with the active agreement of the parties exchanging them. Types in this tree cannot be registered.
According to the previous version of RFC 6838 - obsoleted RFC 2048 (published in November 1996) it should rarely, if ever, be necessary to use unregistered experimental types, and as such use of both "x-" and "x." forms is discouraged. Previous versions of that RFC - RFC 1590 and RFC 1521 stated that the use of "x-" notation for the sub-type name may be used for unregistered and private sub-types, but this recommendation was obsoleted in November 1996.
type / x. media type name [+suffix]
So its clear that the standard type MIME type application/pdf is the appropriate one to use while you should avoid using the obsolete and unregistered x- media type as stated in RFC 2048 and RFC 6838.
This is a convention defined in RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
Private [subtype] values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized.
New standard values should be registered with IANA as described in RFC 2048.
A similar restriction applies to the top-level type. From the same source,
If another top-level type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid a potential conflict with a future official name.
(Note that per RFC 2045, "[m]atching of media type and subtype is ALWAYS case-insensitive", so there's no difference between the interpretation of 'X-' and 'x-'.)
So it's fair to guess that "application/x-foo" was used before the IANA defined "application/foo". And it still might be used by folks who aren't aware of the IANA token assignment.
As Chris Hanson said MIME types are controlled by the IANA. This is detailed in RFC 2048 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. According to RFC 3778, which is cited by the IANA as the definition for "application/pdf",
The application/pdf media type was first registered in 1993 by Paul Lindner for use by the gopher protocol; the registration was subsequently updated in 1994 by Steve Zilles.
The type "application/pdf" has been around for well over a decade. So it seems to me that wherever "application/x-pdf" has been used in new apps, the decision may not have been deliberate.
This is a convention defined in RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
Private [subtype] values (starting with "X-") may be defined bilaterally between two cooperating agents without outside registration or standardization. Such values cannot be registered or standardized.
New standard values should be registered with IANA as described in RFC 2048.
A similar restriction applies to the top-level type. From the same source,
If another top-level type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid a potential conflict with a future official name.
(Note that per RFC 2045, "[m]atching of media type and subtype is ALWAYS case-insensitive", so there's no difference between the interpretation of 'X-' and 'x-'.)
So it's fair to guess that "application/x-foo" was used before the IANA defined "application/foo". And it still might be used by folks who aren't aware of the IANA token assignment.
As Chris Hanson said MIME types are controlled by the IANA. This is detailed in RFC 2048 - Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. According to RFC 3778, which is cited by the IANA as the definition for "application/pdf",
The application/pdf media type was first registered in 1993 by Paul Lindner for use by the gopher protocol; the registration was subsequently updated in 1994 by Steve Zilles.
The type "application/pdf" has been around for well over a decade. So it seems to me that wherever "application/x-pdf" has been used in new apps, the decision may not have been deliberate.
From Wikipedia Media type,
A media type is composed of a type, a subtype, and optional parameters. As an example, an HTML file might be designated text/html; charset=UTF-8.
Media type consists of top-level type name and sub-type name, which is further structured into so-called "trees".
top-level type name / subtype name [ ; parameters ]
top-level type name / [ tree. ] subtype name [ +suffix ] [ ; parameters ]
All media types should be registered using the IANA registration procedures. Currently the following trees are created: standard, vendor, personal or vanity, unregistered x.
Standard:
Media types in the standards tree do not use any tree facet (prefix).
type / media type name [+suffix]
Examples: "application/xhtml+xml", "image/png"
Vendor:
Vendor tree is used for media types associated with publicly available products. It uses
vnd.facet.
type / vnd. media type name [+suffix] - used in the case of well-known producer
type / vnd. producer's name followed by media type name [+suffix] - producer's name must be approved by IANA
type / vnd. producer's name followed by product's name [+suffix] - producer's name must be approved by IANA
Personal or Vanity tree:
Personal or Vanity tree includes media types created experimentally or as part of products that are not distributed commercially. It uses
prs.facet.
type / prs. media type name [+suffix]
Unregistered x. tree:
The "x." tree may be used for media types intended exclusively for use in private, local environments and only with the active agreement of the parties exchanging them. Types in this tree cannot be registered.
According to the previous version of RFC 6838 - obsoleted RFC 2048 (published in November 1996) it should rarely, if ever, be necessary to use unregistered experimental types, and as such use of both "x-" and "x." forms is discouraged. Previous versions of that RFC - RFC 1590 and RFC 1521 stated that the use of "x-" notation for the sub-type name may be used for unregistered and private sub-types, but this recommendation was obsoleted in November 1996.
type / x. media type name [+suffix]
So its clear that the standard type MIME type application/pdf is the appropriate one to use while you should avoid using the obsolete and unregistered x- media type as stated in RFC 2048 and RFC 6838.
Source: Stackoverflow.com