Json file not found ошибка

I have a json file in a Content folder within my asp.net project:

<projectName>
    Content
        NBCCJr.json

…and the code to access it:

$.getJSON('~/Content/NBCCJr.json', function (data) {
    $.each(data, function(i, dataPoint) {
        // Bla
      });
  });
)

…but nothing happens when the code is called; the browser console says, «Failed to load resource: the server responded with a status of 404 (Not Found)»

Why is it not found? Isn’t «tilde whack filename» the correct route to the file?

UPDATE

I also tried it with the «whacks» backwards:

$.getJSON('~ContentNBCCJr.json', function (data) {

…and got the same result («Failed to load resource: the server responded with a status of 404 (Not Found)«)

UPDATE 2

Then I tried it sans a prepended whack thusly:

$.getJSON('Content/NBCCJr.json', function (data) {

…and I get this ambiguous message in the console:

*GET http://localhost:9702/Content/NBCCJr.json 404 (Not Found) jquery.js:8724
XHR finished loading: "http://localhost:9702/Content/NBCCJr.json".*

So it was not found and yet loaded anyway?

UPDATE 3

When I attempted to navigate to the file in the browser by changing:

http://localhost:9702/Default.cshtml

…to:

http://localhost:9702/Content/NBCCJr.json

I got an informative WSOD message from Vint Cerf, Tim Berners-Lee, and/or Al Gore saying:

HTTP Error 404.3 — Not Found
The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.

UPDATE 4

Thanks to JAM, it is now working.

I had to add this to Web.Config:

  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".json" mimeType="application/json" />
    </staticContent>
  </system.webServer>

Prerequisites

• [v ] Can you reproduce the problem in a fresh installation of the «develop» branch?
  yes
• [v ] Do you have any errors in the PHP error log, or javascript console?
  [proxy_fcgi:error] [pid 15262] [client ###.###.###.###:64265] AH01071: Got error 'Primary script unknownn'
• [v ] Did you check the osTicket forums?
• [v ] Did you perform a cursory search to see if your bug or enhancement is already reported?

For more information on how to write a good bug report

Description

cannot access tickets.json file

Steps to Reproduce

1. open http://www.help-desk.tld/office/api/http.php/tickets.json in browser
2. says url not supported.
3. open http://www.help-desk.tld/office/api/tickets.json in browser
4. says file not found.
   Expected behavior: [What you expected to happen]
   I’d expect JSON to appear in the browser
   Actual behavior: [What actually happened]

for http://www.help-desk.tld/office/api/http.php/tickets.json:

Warning: Declaration of AssignmentForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /home/admin/domains/help-desk.tld/public_html/office/include/class.forms.php on line 4367

Warning: Declaration of TransferForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /home/admin/domains/help-desk.tld/public_html/office/include/class.forms.php on line 4487
URL not supported

for the other it doesn’t print any PHP errors.

Versions

Admin panel -> Dashboard -> Information which also additionally gives you information about you server.

Serverinfo
--
osTicket versie | v1.10.1 (9ae093d) —  Bij de tijd
Web Server Software | Apache/2
MySQLversie | 5.6.26
PHPversie | 7.0.14

gdlib | Ten behoeve van afbeeldingsbewerking en PDFprinten
imap | Ten behoeve van emailontvangst
xml | XML API
xml-dom | Ten behoeve van emailverwerking
json | Bevordert de prestaties bij het creeren en verwerken van JSON
mbstring | Hoogst aanbevolen bij niet westeuropese taalinhoud
phar | Hoogst aanbevolen voor plugins en taalpakketten
intl | Hoogst aanbevolen bij niet westeuropese taalinhoud
fileinfo | wordt gebruikt om bestandstypen van uploads te detecteren
APCu | Verbetert de algehele prestaties
Zend Opcache | Verbetert de algehele prestaties

cgi.fix_pathinfo | "1" is aanbevolen als AJAX niet werkt
date.timezone | Europe/Amsterdam

happens in all browsers.

FAQ: Why do my script translations not get loaded from JSON files

See general information on JSON support in Loco Translate before reading this.

When a plugin or theme loads script translations it derives the name of a .json file from the .js file which uses them.
Loco Translate must match these names exactly when it compiles JSON translation files. Any difference in these two names is a likely point of failure.

How can it go wrong?

Suppose a plugin (called «my-plugin») loads a JavaScript file using some code like this that points to the script’s URL:

wp_enqueue_script( 'my-script', plugins_url('scripts/example.min.js', __FILE__) );

WordPress later removes the .min and hashes the file path to produce a JSON file called (for example) my-plugin-fr_FR-72e8c5e24e35642471d54763afbb6a54.json

As per our example on the earlier page Loco Translate must produce the exact same file path by finding references to «scripts/example.js» in the PO file against each string that the script uses. This is very error prone and things can go wrong on both sides.

1. If the file reference in the PO file is wrong, script translation will fail.
2. If the path used in the PHP code is wrong, script translation will fail.

1. Loco Translate is generating the wrong .json file name

This is possible. Check the PO file and look for the file references against the relevant strings. Switch the editor into «code» mode will show clickable file references above the source text.
You can see from here if it references files that don’t exist, or are somehow different.

Note in our example that a .min.js file is loaded, but just .js is used to compute the hash. This is correct but is the only path normalization that WordPress will perform.
Likewise, it is the only normalization that Loco Translate will perform.

However, neither WordPress nor Loco Translate could arrive at scripts/example.js if the deployed script was compiled from files such as sources/widget/component.js,
so ensure that such source references are not appearing in your PO files. This is likely a problem with string extraction, so contact the person who originally generated these references.

2. The script file loads but the path is wrong

Less likely, but it happens. Even if the .js file is loaded successfully this doesn’t mean the path isn’t «wrong».

For example: foo/bar.js and foo/baz/../bar.js point to the same file and your browser will load either of them, but they are not the same and will produce different JSON file names under the WordPress system. The simplest way to fix this would be to contact the author of the code that calls wp_enqueue_script and convince them it’s a bug. Otherwise you’re looking a regenerating PO files with matching references or writing a filter to modify them.

Have you tried removing the ~ ?

As in:

$.getJSON('/Content/dumboJr.json', function (data) {
    $.each(data, function(i, dataPoint) {
        // Bla
      });
  });
)

To allow the IIS to serve JSON files, try adding this to your web.config:

<staticContent>
    <mimeMap fileExtension=".json" mimeType="application/json" />
</staticContent>