Памылкі 407 проксі са знешніх DTD і XML-рэсурсаў

Прасочвайце нечаканую памылку 407 падчас пераўтварэння дакумента да знешніх DTD, схем або іншых рэсурсаў, якія адкрывае парсер.

Лакальны дакумент таксама можа выклікаць 407 падчас пераўтварэння. Яго XML можа згадваць DTD, схему або сутнасць, а рэндэрэр можа загружаць стылі ці выявы. Кліент, які дае збой, можа знаходзіцца ўнутры гэтага парсера пасля завяршэння першапачатковага спампоўвання.

Захавайце трасіроўку выключэння і запытаны URI, затым супастаўце іх з аб'явамі ўваходных даных або спасылкамі на рэсурсы. Запыт DTD да стандартнага хоста — гэта іншая аперацыя, чым запыт старонкі. Пераўтварэнне HTML у PDF таксама можа збаіць падчас атрымання аддаленых рэсурсаў.

Для ўваходных даных .NET XmlReader, кантракт якіх забараняе DTD і знешняе развязанне, выкарыстоўвайце:

var settings = new XmlReaderSettings
{
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};

Перадайце гэтыя налады кампаненту, які фактычна аналізуе дакумент. DtdProcessing вызначае, як апрацоўваць DTD; XmlResolver кіруе знешнім доступам. Prohibit адхіляе дакумент з DTD—ён не выдаляе аб'яву. Калі працэс патрабуе яе, выберыце ўзгодненае лакальнае развязанне або resolver з явным маршрутам.

Трымайце значэнні па змаўчанні прывязанымі да API/асяроддзя выканання. XmlReaderSettings па змаўчанні выкарыстоўвае Prohibit, а яго resolver па змаўчанні змяніўся на null пачынаючы з .NET Framework 4.5.2. Старонні канвертар можа перагледзець гэтыя налады або выкарыстаць іншы парсер.

Змена аб'явы XHTML на HTML doctype можа паўплываць на адзін канвертар, але не наладжвае яго проксі. Вызначце патрабаваныя рэсурсы і палітыку іх загрузкі; аўтэнтыфікацыя ў кліенце першапачатковай старонкі не аўтэнтыфікуе гэты другі кліент.

Падобныя артыкулы