When SketchUp is installed, the Content Type in the registry is entered as “SKP”, causing uploads to have an invalid MIME-type.
Registry location: HKEY_CLASSES_ROOT/.skp, key “Content Type”.
See example workaround here:
https://itslearning.zendesk.com/hc/en-us/articles/202343871-Problem-with-uploading-Sketchup-skp-files
I can confirm that, on my installation, the referenced registry entry is “SKP”. After a bit of self-education through Wikipedia, I can also confirm that “SKP” is not a valid entry in a “Content Type” registry entry.
However, speaking for myself only, this has not caused a problem.
@magnus: Can you provide a use case where this causes a problem?
Disclaimer: I’m am nowhere near an expert, nor even well educated, in this area. My reply is simply to confirm the reported behavior (value in Registry) on another SketchUp installation. My closing question resulted from my wondering “Where might this be a problem?” and “Might it affect me?”
For my particular use case, we use an issue-tracking web application that you can choose “Reply as Email” and attach files. That application uses a well known java library for sending smtp emails which uses the MIME type from the uploaded files to attach them… This generates the following error:
org.springframework.mail.MailSendException; nested exception details (1) are: Failed message 1: javax.mail.internet.ParseException: Expected '/', got null at javax.mail.internet.ContentType.<init>(ContentType.java:102) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1331) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1021) at javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:419) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1354) at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2107) at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2075) at org.springframework.mail.javamail.JavaMailSenderImpl.doSend(JavaMailSenderImpl.java:398) at org.springframework.mail.javamail.JavaMailSenderImpl.send(JavaMailSenderImpl.java:342) at org.springframework.mail.javamail.JavaMailSenderImpl.send(JavaMailSenderImpl.java:338) ...call-stack from the issue-tracking software...
In more general terms, this might cause problems in applications that saves the MIME type for uploaded files and later uses it, for one reason or another… Most likely by attaching them in emails, or for downloads (although my guess is that browser downloads might be more forgiving, and fall back to something like “application/octet-stream”)
Best workaround would be to either remove the Content Type key from the registry completely (unless it is actually used for something) or use one that complies with the standard. Something like “application/vnd.sketchup.skp” that is suggested here
OK. I now grok why it can be a problem. While you propose these as workarounds, I think that Trimble should correct the registry to your suggestion (or something else that makes sense that they’ve used before). Towards that end, I’m going to tag a few Sketchup Team Members to make sure this comes to their attention (and is hopefully included in the next maintenance release!):
@Barry @Marc @yogesh
Finally, since I’m using SU 2017 Pro, in order to determine if this is a new problem (since you don’t list your SketchUp version in your profile), I invite someone who hasn’t tried to install SU 2017 for Windows - and is using SU 2016 for windows - to let us know what value is in your Registry for: HKEY_CLASSES_ROOT/.skp, key “Content Type”
I have never had any problem either.
Agree. It is not.
But according to this document page:
https://www.w3.org/Protocols/rfc1341/4_Content-Type.html
When a mail reader encounters mail with an unknown Content- type value, it should generally treat it as equivalent to “application/octet-stream”, as described later in this document.
So it goes into greater detail about default behavior later in the document “somewhere”.
But I would submit that the term “mail reader” should apply to any client application of whatever kind, ie, browser, etc.
For another example, see RFC 2077, which describes one of the newest main content types “model”.
4. Encoding and Transport
a. Unrecognized subtypes of model should at a minimum be treated
as “application/octet-stream”.
…
In the future, when SketchUp “.skp” and “.skb” resources get their own registered content types / mime types / media types, they will be registered as vendor specific, under the model main type (not the application main type.)
Example:
".skp" model/vnd.sketchup.model.binary
".skb" model/vnd.sketchup.model.binary.backup
I guess the “.binary” is unneeded as RFC 2077 says binary format is assumed unless otherwise stated.
I would expect that the other non-model SketchUp file resources (“.skm”, “.skc”, “.layout”, etc.,) would have media types that begin with:
“application/vnd.sketchup.”
For more information on media types, see:
I like the latter, rather than the former. But this will not fix all the old installers (and installations) out there “in the wild.” (Unless POSH, GmbH whips out a little utility to do this.)
www.filesuffix.com (and sites like it,) are not an authority, although this one gets close with a suggested media type.
Obviously the media type will be vendor specific. And because the product keeps changing hands every 4 years or so, I don’t think it is desirable to use something like:
model/vnd.trimble-nav.sketchup.model.document
But IMO, the fault lies with your issue tracker app, and / or the Java library it uses.
It should trap the error, and fallback (as you guessed, and the specifications say,) to “application/octet-stream” media type.
Yeah, I’m not read up on how these things are officially determined (and frankly, it’s not my thing to worry about either). That was just an example of how it might look like. But the things mentioned above seems much better then my suggestion anyways, so you seem to be on top of things… 
[quote=“DanRathbun, post:6, topic:35193”]
But IMO, the fault lies with your issue tracker app, and / or the Java library it uses.
It should trap the error, and fallback (as you guessed, and the specifications say,) to “application/octet-stream” media type.
[/quote]
I agree, and that is what I suggested to them… (Although they put the blame on SketchUp for having an invalid Content Type )
Now, for us, it’s not a major issue, and we can just apply a group policy to force it to be whatever we want. I just wanted to report it so it might be fixed one way or another in the future, and perhaps prevent others from having similar issues.
Thank you for your quick feedback! 
Yes, it is an interesting topic.
There also may need to be another key created in
“HKCR\MIME\Database\Content Type”
… for each new media type SketchUp uses.
Hi folks-
I bumped this discussion over to the team in charge of the windows installer, so hopefully we’ll get a resolution that way.
Thanks for the report.
-m
And I looked into our discussions from many years ago at Google about registering MIME types, but a music program has a number of those registered already (skp, skm etc…).
You are right. Usage of MIME has expanded considerably from its origin as “Multipurpose Internet Mail Extensions”, becoming the standard for designating data in general on the Internet. Most likely nobody has bothered to update that document in the meantime.
I don’t see them on this list, which was updated last Dec:
http://www.iana.org/assignments/media-types/media-types.xhtml
ADD: A media type can have more than one file extension associated with it.
The SketchUp file extension could be expanded to avoid clashing with “the music app” files.
ie:
.skm > .skmat, .skmtl
.skp > .skdoc
.skb > .skbak
.skc > .skcls
.rbz > .skexz
.strings > .skloc
.style > .sksty
.layout > .sklay
Credit @magnus with the discovery. And don’t forget to bless him with the “Bug Catcher” badge when you confirm the bug!
Old thread, but reviving it again…
It seems that this issue still persists. This time, we noticed that we can’t upload .skp files to Jira if we have SketchUp installed (2018/2019). It works fine as long as we upload from a computer without SketchUp.
Soooo, I guess nobody ever did anything about this?
(The registry key is still the invalid “SKP” value)
I think it’s been covered above. We attach skp’s to Jira without issues.
Found a gem while working through why WordPress and a bunch of other apps have no idea what an “.skp” file is or on those that do, the mime type is “application/x-koan”.
Turns out the SketchUp devs basically stole a file extension/mime-type from an old audio app/format, “Koan” from SSEYO:
https://www.iana.org/assignments/media-types/application/vnd.koan
The four necessary file extensions are as follows :
.skd - SSEYO Koan Design file, authored using SSEYO Koan Pro.
.skp - SSEYO Koan Play file - an encrypted version of an .skd file,
created from SSEYO Koan Pro, which can be played through the
Koan Web and Koan Plugins. SKP files cannot be loaded by Koan
Pro, making it a useful format for distributing Koan pieces
where you do not want the techniques you have used to be
seen by others.
.skm - SSEYO Koan Mix file - a user-remix of an .skp file.
.skt - SSEYO Koan Tempate file - used as the template of ideas for Koan
Pro.
I imagine that SSEYO is mostly defunct these days, but seeing that Brian Eno used their “generative music” creator, we can’t assume the file format is not still being actively used. Oops.
So next time you have a SketchUp MIME issue, you’ll know part of the problem is that everyone that’s pulling MIME info from IANA’s official list is thinking you’re dealing with not a CAD file but an audio file of some sort. 
When you look for any three-letter file extension, your search usually gives you several quite unrelated file type options.
SSEYO has probably stolen the letters from the Finnish Communist Party (also mostly defunct), they have used the acronym from the year 1918 when it was founded.
From my search I found that there were somewhere between 1000…2000 copies of Koan Pro sold.
Compare to like 10s of millions (or more) of installed SketchUp editions.
While the suggested MIME type (now known as “Media Type”,) in the memo (dated 1996) was "application/x-koan". IANA no longer uses x- subtypes. (See RFC6838, page 6, section 3.4)
The media type as registered (or changed to / currently) is "application/vnd.koan".
Well back in 2000 it was 2 college guys before they formed @Last Software. Give 'em a bit of a break.
And was MIME content type so important back then ?
I seem to remember that everyone thought that the world was going to come crashing to a halt because of the 2K date bug. (Which didn’t happen. We just installed a patch and kept on computing’ whilst the doomsayers kept preaching about the end of the world. When after new years 2000 the world was still here, the “preachers” just choose something else, … a grand conjunction of the planets or a comet to come or whatever, to be the next destroyer of the world. And so on, again and again.)
Not many people are having issues.
And as said above, the registry key value can easily be changed to "application/octet-stream" , or even the yet unregistered … "model/vnd.sketchup". When a system encounters the latter and doesn’t recognize it, then the former should be used as a default (according to IANA specification.)