It seems, that RapiDoc is very strict with the evaluating of the content type. This can cause several issues, since it is very common to use a 3rd party web framework (or a 3rd library) and so the response header is not always in complete control of the user.
It would be beneficial, if RapiDoc ignores any additional data after the actual content type. Since content type headers can carry additional custom metadata, it should be allowed.
Example issue:
The server sends as a response header the content type application/gzip;charset=UTF-8 instead of application/gzip. This causes RapiDoc to show the file content in the RapiDoc UI (which causes performance issues) instead of showing a download button.
It seems, that RapiDoc is very strict with the evaluating of the content type. This can cause several issues, since it is very common to use a 3rd party web framework (or a 3rd library) and so the response header is not always in complete control of the user.
It would be beneficial, if RapiDoc ignores any additional data after the actual content type. Since content type headers can carry additional custom metadata, it should be allowed.
Example issue: The server sends as a response header the content type
application/gzip;charset=UTF-8instead ofapplication/gzip. This causes RapiDoc to show the file content in the RapiDoc UI (which causes performance issues) instead of showing a download button.