Inability to upload files with a .har extention to an Incident record

[Edward Rosario]

The other day, I was helping someone who needed to attach a .har file to an incident in ServiceNow. Simple enough, right? Just drag and drop the file. But nope — ServiceNow wasn’t having it. The upload was blocked, and the user was stuck.

At first, I thought, “Okay, it’s probably the file extension thing.” ServiceNow has a property called glide.attachment.extensions that controls which file extensions are allowed. If you list out extensions there (like pdf, xls, doc), ServiceNow only accepts those. If you leave it blank, it should accept everything.

In this case, it was blank. So extensions weren’t the problem.

Digging Deeper

That’s when I remembered another property that can mess with uploads: glide.security.file.mime_type.validation.

When this one is turned on, ServiceNow doesn’t just look at the extension — it actually checks the file’s MIME type (what the browser says the file is). Then it compares that against the System MIME Types table (sys_mime_type).

And if it doesn’t find a match? Blocked.

That’s exactly what was happening here. .har files usually come through as application/json or sometimes application/octet-stream, but ServiceNow had no idea what to do with .har. Since there was no entry for it in the MIME type list, the upload got denied.

The Fix

Once I figured that out, the solution was straightforward:

• The “clean” fix was to add .har to the MIME Types table with something like:
• Extension: har
• MIME type: application/json
• The “quick but not great” fix would be to turn off glide.security.file.mime_type.validation. That works too, but it lowers security, so I wouldn’t recommend it unless you’re just testing.

Lesson Learned

What I took away from this is that ServiceNow attachments aren’t just about extensions. You might think leaving the extension list blank means “everything goes,” but MIME type validation can still stop you in your tracks.

So next time a file won’t attach, I’ll know to check both places — and not just blame the poor extension list.