To reproduce: 1. Pick any XUL file, chrome/addressbook/content/default/abNewCardDialog.xul, that references to an external DTD file. 2. Edit the system id to the DTD file to use 'http' type URL, say "http://tiger/chrome/addressbook/locale/da-DK/abNewCardDialog.dtd" as listed in the URL field. 3. On Linux, the client dies without a trace. On NT, the call stack follows. NTDLL! 77f76148() nsDebug::Error(char * 0x0a7a0dcc, char * 0x0a7a0d88, int 170) line 204 + 13 bytes nsHTTPChannel::OpenInputStream(nsHTTPChannel * const 0x0ac75650, unsigned int 0, int -1, nsIInputStream * * 0x0012fab4) line 170 + 21 bytes NS_OpenURI(nsIInputStream * * 0x0012fb50, nsIURI * 0x0ac751d0) line 79 + 20 bytes nsExpatTokenizer::OpenInputStream(const nsString & {...}, const nsString & {...}, nsIInputStream * * 0x0012fb50, nsString * 0x0012fb78) line 558 + 13 bytes nsExpatTokenizer::HandleExternalEntityRef(void * 0x01321fb0, char * 0x00000000, char * 0x0a5a72d8, char * 0x0a5a73aa, char * 0x00000000) line 630 + 21 bytes doProlog(void * 0x01321fb0, const encoding * 0x01723878, char * 0x0a59ec54, char * 0x0a59f166, int 17, char * 0x0a59ec56, char * * 0x0012fc78) line 2248 + 36 bytes prologProcessor(void * 0x01321fb0, char * 0x0a59e348, char * 0x0a59f166, char * * 0x0012fc78) line 2132 + 36 bytes prologInitProcessor(void * 0x01321fb0, char * 0x0a59e348, char * 0x0a59f166, char * * 0x0012fc78) line 2121 + 21 bytes XML_Parse(void * 0x01321fb0, char * 0x0a59e348, int 3614, int 0) line 852 + 40 bytes nsExpatTokenizer::ParseXMLBuffer(char * 0x0a59e348, unsigned int 3614, int 0) line 286 + 24 bytes nsExpatTokenizer::ConsumeToken(nsScanner & {...}) line 329 + 18 bytes nsParser::Tokenize(int 0) line 1264 + 21 bytes nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 885 + 12 bytes nsParser::OnDataAvailable(nsParser * const 0x0a575eb4, nsIChannel * 0x0ac70580, nsISupports * 0x00000000, nsIInputStream * 0x0ac71f50, unsigned int 0, unsigned int 1807) line 1168 + 19 bytes nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x0ac70750, nsIChannel * 0x0ac70580, nsISupports * 0x00000000, nsIInputStream * 0x0ac71f50, unsigned int 0, unsigned int 1807) line 2057 + 32 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0ac72460) line 350 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0ac72464) line 149 + 12 bytes PL_HandleEvent(PLEvent * 0x0ac72464) line 509 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00e23da0) line 470 + 9 bytes _md_EventReceiverProc(void * 0x00e60134, unsigned int 49215, unsigned int 0, long 14826912) line 932 + 9 bytes USER32! 77e713ed() 4. The DTD file loads fine with file/resource type of URL. Java script source reference works with both http and file (resource) types URL. This bug prevents us from loading DTD files from remote hosts. Hi, Warren/Judson: I saw the "blocking stream" discussion in the newsgroup. Could we load http type URL as blocking stream from XML parser?

currently http doesn't support blocking reads (not a particularly good thing to begin with because the blocking load would lock up whatever thread the load is occuring on). *** This bug has been marked as a duplicate of 11112 ***

HI, Nisheeth: I think there are two problems here: 1. HTTP does not support blocking read. 2. DTD loading is synchronous. XML parser needs to able to load DTD asychronously. I remembered James Clark commented on asynch loading a while ago. Is he still working on this? I'm changing the summary and including James on the CC list. Reopen the bug.

Clear the resolution. Hi, Nisheeth: Would you work with James and Warren's team to see if we can load DTD asynchronously.

*** This bug has been marked as a duplicate of 0456 ***

Do you mean a dup of 10456 in stead of 0456?

Yes, 10456.

My original comment was that it was a bad idea for the browser to parse DTDs because it was impractical to load them asynchronously, and that therefore an different approach to localization should be used. Expat cannot deal with parsing a DTD after it's parsed the document which uses the DTD. This would be really hard to support. I think the short-term solution is to fake it in the nsExpatTokenizer glue code. nsExpatTokenizer would maintain a stack of buffers. When you get a request to load an external parameter entity or DTD, you arrange that input for the parent entity gets stored in the buffer instead of going straight to the XML_Parser object for that entity. When the loading of the external parameter entity or DTD completes, you then pass any buffered input on to the XML_Parser object and stop buffering the input for that XML_Parser object. Also it's important not to load DTDs unless you really need to (use XML_PARAM_ENTITY_PARSING_UNLESS_STANDALONE not XML_PARAM_ENTITY_PARSING_ALWAYS).

Hi, Warren/Jud: You marked this bug as a dup of 10456/11112. Does this mean when 10456 gets fixed, we'll be able to load DTD with http type URLs automatically? If not, please reopen the bug. As James suggested that we might need to do the async loading in the nsExpatTokenizer glue code. Thanks

Nisheeth: I am reopening the bug unless there is an objection. Please do not resolve this bug as a dup of bug 10456 unless we are confident that fixing 10456 will automatically fix this bug. Thanks

Accepting bug and setting milestone to M12...

As James pointed out, when we added parameter entity support, we did so knowing that the DTDs would need to get loaded synchronously. Its going to be difficult for me to work on making DTD loading asynchronous before beta. I'm keeping this bug around for post-beta work, though. If my schedule permits it, I'll try to get this fixed then. Setting target milestone to M14...

Adding lyecies@netscape.com to cc list.

*** Bug 12486 has been marked as a duplicate of this bug. ***

*** Bug 17236 has been marked as a duplicate of this bug. ***

Changing the severity to normal.

Bulk moving all M14 non-beta stopper bugs to M17...

*** This bug has been marked as a duplicate of 22942 ***

verified dup