Предполагая, что вы заходите на страницу через http://localhost:8080/page
или что-то в этом роде, вы должны обслуживать свой контент с помощью этого подхода.По сути, вместо того, чтобы предоставлять файлы в качестве путей в локальной файловой системе, вы должны создать маршрут приложения и связать его с обработчиком, а не извлечь соответствующий PDF из локальной файловой системы, а затем отправить обратно ответ, содержащий Content-Type: application/pdf
в HTTPЗаголовки ответа и байты файла PDF в теле ответа.
Чтобы не дублировать чужое решение для описанного подхода, я бы рекомендовал взглянуть на этот ответ для "Колбаобработка PDF как отдельной страницы ".
Поскольку вы технически отправляете ответ обратно с localhost
- или с любым именем, которому вы его обслуживаете - вместо того, чтобы пытаться загрузитьЛокальный файл непосредственно с веб-страницы клиента, Chrome не должен выдавать никаких жалоб.
Конечно, стоит отметить, что при определении файла для загрузки следует руководствоваться рекомендациями.ничего больше, чем учебный проект.В любой законной системе, которая выполняла подобные действия, было бы необходимо выполнить проверку запрошенных файлов, чтобы гарантировать, что злонамеренный пользователь не злоупотребляет приложением для утечки файлов из локальной файловой системы, помимо тех файлов, которые предназначены для обслуживания.(Для этого у вас обычно может быть элемент src
, содержащий параметр, для которого задан хэш / уникальный идентификатор файла, который затем отображается в некоторой базе данных на правильный путь к файлу. В качестве альтернативы вы можете использоватьпараметр в src
, который содержит имя файла без полного пути, а затем убедитесь, что предоставленное пользователем значение для этого параметра в запросе не содержит никаких символов вне кодировки, например [a-zA-Z0-9_-]
.) В конечном счете,Похоже, что это конкретное предупреждение не относится к вашему делу, но все же предоставляет его на тот случай, если кто-нибудь еще прочтет это в будущем.