Closed Bug 11538 Opened 21 years ago Closed 20 years ago

[XML] XML parser needs to load http type external DTD asychronously

Categories

(Core :: XML, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 22942

People

(Reporter: tao, Assigned: nisheeth_mozilla)

References

()

Details

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?
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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 ***
Status: RESOLVED → REOPENED
Summary: [XML] XML parser can't load external DTD with 'http' type system ID → [XML] XML parser needs to load http type external DTD asychronously
Whiteboard: XML parser needs to load http type external DTD asychronously
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.
Resolution: DUPLICATE → ---
Clear the resolution.

Hi, Nisheeth:


Would you work with James and Warren's team to see if we can load DTD
asynchronously.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → DUPLICATE
*** 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
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
Status: REOPENED → ASSIGNED
Target Milestone: M12
Accepting bug and setting milestone to M12...
Target Milestone: M12 → M14
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. ***
Severity: critical → normal
Whiteboard: XML parser needs to load http type external DTD asychronously
Changing the severity to normal.
Blocks: 17907
No longer blocks: 17907
Bulk moving all M14 non-beta stopper bugs to M17...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 22942 ***
Status: RESOLVED → VERIFIED
verified dup
You need to log in before you can comment on or make changes to this bug.