Closed
Bug 186632
Opened 23 years ago
Closed 23 years ago
well-formed xml fails parsing with a "no element found" error
Categories
(Core :: XML, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: weeber51, Assigned: hjtoi-bugzilla)
References
()
Details
Attachments
(4 files)
User-Agent: Mozilla/4.0 (compatible; MSIE 6.72; Windows 2000) [en] (UNIX)
Build Identifier:
when trying to open http://www.whirlywiryweb.com/ , parsing fails:
XML Parsing Error: no element found
Location: http://www.whirlywiryweb.com/
Line Number 30, Column 145:
however, the document does not appear to have any errors. also,
http://www.whirlywiryweb.com/q%2Fgetheaders.asp parses into content from i don't
know where. not sure if that's related.
Reproducible: Always
Steps to Reproduce:
1.go to http://www.whirlywiryweb.com/
Comment 1•23 years ago
|
||
> Build Identifier:
That's not useful. What build are you using?
Mozilla/4.0 (compatible; MSIE 6.72; Windows 2000) [en] (UNIX)
Build ID: 2002121608
just a few days old.
sorry, i recently cleaned out my profile, and i can no longer reproduce the bug.
however, i've found the problem at
http://www.whirlywiryweb.com/q%2Fgetheaders.asp still happens when the user
agent is set as mine was (to imitate ie). whirlywiryweb.com appears to have ie
and non-ie versions of their pages (which doesn't seem awfully wise since a lot
of browsers send ie's user agent), but mozilla chokes on the ie version. i don't
know whether the page actually has ie-specific code.
also, i noticed that when the user agent is NOT set to ie and is left at the
default gecko one, the pages come up, but with a strange side effect.
1. visit http://www.whirlywiryweb.com/ note what the page looks like
2. now go to http://www.whirlywiryweb.com/q%2Fgetheaders.asp
3. go back to http://www.whirlywiryweb.com/ and reload. the page is now the same
as http://www.whirlywiryweb.com/q%2Fgetheaders.asp
should i file another bug for this?
(tested with Mozilla 1.3a release build on Linux)
When setting the user agent to the same string as the reporter did, the
mentioned website displays an alternative version of its website, based on
XML/XSLT. When viewing this with Mozilla, you get to see the plain content of
the XML file, but not in the threaded way when you open a regular XML file. I'm
not getting errors however (maybe the page changed already?). When validating
the XML file with RXP, I don't get any errors.
This behaviour is IMHO not a bug in Mozilla, but merely a combination of
manually altering the user agent string, and specific (non-compatible) web design.
Concerning your second remark: the website sends a cookie (when opening an ASP
session) when first visiting the website. Other browsers such as Konqueror and
Lynx display the same behaviour. My guess is the website saves your position on
the website, and restores your position when entering the main URL. Once again,
I don't think this should be classified as a bug, and the bug can be closed.
Not exactly... the XML that Mozilla spits out is not the file's plain content;
it's from somewhere else (not sure where). But I'm not sure if that makes this
issue any more valid...
As for the cookies... the showing the last visited page behavior doesn't occur
in IE, but that may well be because IE uses a different version of the site.
| Assignee | ||
Comment 6•23 years ago
|
||
If somebody could attach the files (XML + XSLT) it would be much easier to see
what's going on...
Base XML file (retrieved by invoking a telnet session to the webserver, details
below)
GET http://www.whirlywiryweb.com/ HTTP/1.1
Host: www.whirlywiryweb.com
user-agent: Mozilla/4.0 (compatible; MSIE 6.72; Windows 2000) [en] (UNIX)
HTTP/1.1 200 OK
Date: Mon, 06 Jan 2003 18:36:26 GMT
Content-Length: 12398
Content-Type: text/xml
Expires: Mon, 06 Jan 2003 18:36:26 GMT
Cache-Control: no-cache
Connection: close
Server: Microsoft-IIS/5.0
Set-Cookie: ASPSESSIONIDAARATRCD=AJHKGGLADDKDODPCCECJEHBH; path=/
Via: 1.1 xxxxxxxx (NetCache NetApp/5.2.1R1D4)
This stylesheet is referenced in the main stylesheet. However loading this in
Mozilla yields the following error:
<parsererror>
XML Parsing Error: xml processing instruction not at start of external entity
Location: http://www.whirlywiryweb.com/common/art_i.xsl
Line Number 1, Column 4:
<sourcetext> <?xml version="1.0"?>
---^</sourcetext>
</parsererror>
Comment 10•23 years ago
|
||
| Assignee | ||
Comment 11•23 years ago
|
||
Ok, there are several errors in the XML files, so it is not Mozilla's fault that
they don't display as you'd expect them to. For example, the namespace in the
XSLT files is wrong (the old XSLT Working Draft namespace) and even more
seriously one of the XML files is not even well-formed (an XML file MUST NOT
start with whitespace).
This bug is INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•