We have an active Exalate connection syncing issues between a Jira instance and a ServiceNow instance.
We encountered an issue where an attachment fails MIME type validation on the ServiceNow side during sync, causing the following error:
“Response received from ServiceNow while Adding attachment [filename].txt with status 400: Message: Invalid file type: text/html, None”
The file has a .txt extension but is being identified as text/html by ServiceNow, which then rejects it. This appears to happen because ServiceNow inspects the actual file content rather than relying solely on the file extension (MIME type checking).
Disabling MIME type checking on ServiceNow is an option, but since its a global setting… i really don’t want to do that
Has anyone run into this? Is there a recommended workaround or a way to handle this type of MIME validation error on the Exalate side?
If disabling MIME type validation globally isn’t an option, one workaround would be to filter out those attachments in the Exalate script before they’re sent to ServiceNow.
Would that be an acceptable solution in your case, or do those attachments need to be synchronized? Also, does this happen with all .txt files or only specific ones?
Yes, filtering out the affected files would be acceptable.
The tricky part, and what i was wondering, is if there is a way with exalate script to mime type check before sync or filter out the attachment after the error so it wont stop the sync.
The mime type check, fails for the specific .txt file but will generally fail if the extension does not comply with what ServiceNow identifies in the mime type check.
Exalate can’t “retry and skip only the failed attachment” after ServiceNow rejects it, because at that point the sync event already fails on the upload error. So the safer approach is to prevent known problematic files from being included in the replica.
For example, if the issue is mainly with .txt files that ServiceNow detects as HTML, you could try the following in the Jira Outgoing sync:
,
.