В теории, в соответствии с RFC 4329 , application/javascript.
Причина, по которой это предполагается application, не связана с тем, является ли тип читаемым или исполняемым. Это связано с тем, что существуют собственные механизмы определения кодировки, установленные самим языком / типом, а не просто общим charsetпараметром. Подтип textдолжен иметь возможность транскодирования через прокси в другую кодировку, изменяя параметр кодировки. Это не верно для JavaScript, потому что:
а. RFC говорит, что пользовательские агенты должны делать BOM-сниффинг сценария, чтобы определить тип (хотя я не уверен, действительно ли какой-либо браузер делает это);
б. браузеры используют другую информацию - включая кодировку страницы, а в некоторых браузерах - script charsetатрибут - для определения кодировки. Таким образом, любой прокси, который пытался перекодировать ресурс, сломал бы его пользователей. (Конечно, в действительности никто никогда не использует транскодирующие прокси в любом случае, но это было намерением.)
Поэтому точные байты файла должны быть сохранены точно , что делает его двоичным applicationтипом, а не технически символьным text.
По той же причине application/xmlофициально предпочтительнее, чем text/xml: XML имеет свои собственные механизмы внутрисхемной сигнализации кодировки. И все applicationтоже игнорируют XML.
text/javascriptи, text/xmlвозможно, это не официальная правильная вещь, но есть то, что все используют сегодня по соображениям совместимости, и причины, по которым они не являются правильными, практически не имеют значения.