Invalid MIME type


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:

1 Like

Cannot upload .skp file to DB via HTTP POST request - Ruby

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>(
        at javax.mail.internet.MimeBodyPart.updateHeaders(
        at javax.mail.internet.MimeBodyPart.updateHeaders(
        at javax.mail.internet.MimeMultipart.updateHeaders(
        at javax.mail.internet.MimeBodyPart.updateHeaders(
        at javax.mail.internet.MimeMessage.updateHeaders(
        at javax.mail.internet.MimeMessage.saveChanges(
        at org.springframework.mail.javamail.JavaMailSenderImpl.doSend(
        at org.springframework.mail.javamail.JavaMailSenderImpl.send(
        at org.springframework.mail.javamail.JavaMailSenderImpl.send( 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:

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.)

".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:

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.) (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:

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… :slight_smile: [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.

I agree, and that is what I suggested to them… (Although they put the blame on SketchUp for having an invalid Content Type :slight_smile:)

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! :+1:

1 Like


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.




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:

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.


.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.