Hello, Sebhof.

What you are describing sounds more like a browser misbehaving, rather than web server. The only way a web server (or a web app) can force a browser to bring up File|Save dialog is if the response has a content-disposition header, something like "Content-Disposition = attachment; filename=test.txt". Otherwise it's up to the browser to decide whether it can render the content as a page, or try to save the response as a file. In general, browsers do treat unfamiliar content types as files. So if, say, browser does not know what to do with text/json response content generated by a URL ending wish .ASPX, it will try to save it as a file, which is exactly what you are describing. To confirm or disprove this theory, would it be possible to point the same browser to a URL generating text/json content generated by another web server and see whether results are different?

Please let us know what you have found.

Best regards,
UltiDev Team.

Sebhof,

Do we understand this correctly that when you point the browser to the JSON app hosted by UltiDev Cassini, you still have a problem, and when you point it the same browser to the same app hosted by IIS, it works fine?

If that's the case we could help you troubleshoot the issue with Cassini. To do that we would need to see the difference between the responses generated by IIS and Cassini. To see the difference, the Fiddler - an HTTP traffic monitoring tool is a great help. Once you install and run it on the same machine as your browser, you can point the browser to your applications (using URLs with either machine name or real IP instead of loopback addresses like localhost and 127.0.0.1) to see both requests and responses traced in the Fiddler. If you could use Fiddler to archive two round-trips to the same Jason URL - one for IIS and another for Cassini, you (or us) should be able to tell what is different in where the problem is.

Please let us know what you have found.

Best regards,
UltiDev Team.