स्थानीय कागजातले पनि रूपान्तरणका क्रममा 407 निम्त्याउन सक्छ। यसको XML ले DTD, स्किमा वा एन्टिटी नाम दिन सक्छ, र रेन्डररले शैली वा तस्बिरहरू ल्याउन सक्छ। असफल हुने क्लाइन्ट मूल डाउनलोड सकिएपछि त्यही पार्सरभित्र हुन सक्छ।

एक्सेप्सन स्ट्याक र अनुरोध गरिएको URI राख्नुहोस्, त्यसपछि तिनलाई इनपुट घोषणा वा स्रोत सन्दर्भसँग मिलाउनुहोस्। मानक होस्टमा DTD अनुरोध पृष्ठ अनुरोधभन्दा फरक कार्य हो। HTML-बाट-PDF रूपान्तरण पनि टाढाका स्रोत ल्याउँदा असफल हुन सक्छ।

जसको सम्झौताले DTD र बाह्य समाधानलाई निषेध गर्छ त्यस्तो .NET XmlReader इनपुटका लागि, प्रयोग गर्नुहोस्:

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

ती सेटिङहरू कागजात वास्तवमै पार्स गर्ने कम्पोनेन्टलाई दिनुहोस्। DtdProcessing ले DTD कसरी ह्यान्डल गर्ने छान्छ; XmlResolver ले बाह्य पहुँच नियन्त्रण गर्छ। Prohibit ले DTD भएको कागजात अस्वीकार गर्छ—यसले घोषणा हटाउँदैन। यदि कार्यप्रवाहलाई एउटा चाहिन्छ भने, स्वीकृत स्थानीय समाधान वा स्पष्ट रूपमा रुट गरिएको resolver छान्नुहोस्।

पूर्वनिर्धारितहरू API/रनटाइमसँग बाँधिएर राख्नुहोस्। XmlReaderSettings ले पूर्वनिर्धारित रूपमा Prohibit प्रयोग गर्छ, र यसको पूर्वनिर्धारित resolver .NET Framework 4.5.2 देखि null भयो। तेस्रो-पक्ष कन्भर्टरले तिनलाई ओभरराइड गर्न वा अर्को पार्सर प्रयोग गर्न सक्छ।

XHTML घोषणालाई HTML doctype मा बदल्दा एउटा कन्भर्टरमा असर पर्न सक्छ, तर यसको प्रोक्सी कन्फिगर गर्दैन। आवश्यक स्रोत र तिनको लोडर नीति निर्धारण गर्नुहोस्; प्रारम्भिक पृष्ठ क्लाइन्टमा प्रमाणीकरणले यो दोस्रो क्लाइन्ट प्रमाणित गर्दैन।

सम्बन्धित लेखहरू