Closed
Bug 110734
Opened 23 years ago
Closed 21 years ago
Report 404 [file not found] for XSLT document
Categories
(Core :: XSLT, defect)
Core
XSLT
Tracking
()
VERIFIED
FIXED
People
(Reporter: WeirdAl, Assigned: peterv)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file)
391 bytes,
text/xml
|
Details |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011116 BuildID: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011116 Loading an XHTML document saved as .xml, I have a missing XSLT document referenced by a <?xml-stylesheet ?> processing instruction. This 404 means the XML parser should ignore the processing instruction; it does not. Reproducible: Always Steps to Reproduce: 1. Load the attached testcase (coming up) Actual Results: Blank page. Expected Results: "If you can read this, you don't need glasses" appears on the page in H1 format. Mozilla 0.9.5 renders the page without the special H1 formatting. So this is definitely a regression on an already bad bug.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Strange... my local copy of said testcase is coming up blank, but the online page is giving me plaintext. :(
Keywords: regression,
testcase
Comment 3•23 years ago
|
||
Neither http://www.w3.org/TR/xml-stylesheet/ nor http://www.w3.org/TR/xslt specify the behaviour for a 404 in a stylesheet. It's an error, and it should be reported. A "just do as if nothing ever happened" is plain wrong, IMHO.
Severity: major → minor
OS: Windows 98 → All
Hardware: PC → All
Summary: 404 XSLT document wipes out rendering of XHTML as XML → Report 404 [file not found] for XSLT document
Comment 4•23 years ago
|
||
bz touched this in the last couple of days, at least for css
Assignee | ||
Comment 5•23 years ago
|
||
CSS stylesheet loading and XSLT stylesheet loading is totally different afaik. I doubt it is related.
Comment 6•22 years ago
|
||
*** Bug 144396 has been marked as a duplicate of this bug. ***
Peter should look at this.
Assignee: keith → peterv
Btw, in the case of CSS we just act as if there was no stylesheet so one could argue the same should happen with XSLT. On the other hand, it is very likely that the data would be totally unusable or seriously wrong, so an error result is also justified. I think I'd prefer seeing an error message. What does IE do?
Comment 9•22 years ago
|
||
IE6 displays this error message when a referenced xslt stylesheet can't be loaded: The XML page cannot be displayed Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later. -------------------------------------------------------------------------------- XML document must have a top level element. Error processing resource '<url>'. In my opinion, an error message like this is the correct behavior. However, when using IE in this manner, I wish it had a link/button/something to display the xml without the stylesheet (perhaps in the spiffy IE xml-pretty printing mode).
Reporter | ||
Comment 10•22 years ago
|
||
IE's behavior is wrong in that they totally deny access to the XML document underneath. They block access to the data. Heikki: why would it be "totally unusable or seriously wrong"? MathML and XHTML are two XML languages Mozilla currently renders (relatively) correctly without XSLT stylesheets; if the stylesheet is 404 or the wrong mimetype (there's been another bug filed for that, which this may be a dupe of), an error is justified, but that doesn't mean the MathML or XHTML aren't any good because the stylesheet's busted... For the record, the Amaya 6.1 editor does give the wrong stylesheet PI, which breaks MathML in Mozilla. Other than that, the MathML Amaya puts out is on very solid ground. (I filed a bug on this, and duped it to that other bug.)
For example, if I send you a P3P policy file in XML, you will have a hard time reading it without a stylesheet. An XSLT stylesheet can order the data in logical order, make summaries, indices, links, and generate content to explain the terse markup. I think this would be a typical situation where XSLT is used: the raw XML is useless to most people, and needs some kind of stylesheet to make any sense for humans. Also it is quite possible that the raw XML would contain information for several mutually excusive situations, needing a stylesheet to show and hide the relevant parts. Without a stylesheet you could easily draw wrong conclusions.
*** Bug 181571 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 13•21 years ago
|
||
Re comment 2: Behavior seems to have changed. In a recent nightly, Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030328 I get a blank gray screen. I'm going to e-mail the W3C lists for xml-stylesheet and XSLT. We really should get an answer on this.
Reporter | ||
Comment 14•21 years ago
|
||
http://lists.w3.org/Archives/Public/xsl-editors/2003JanMar/0040.html
Reporter | ||
Comment 15•21 years ago
|
||
:( W3C hasn't said much yet; the one reply I got says "implementation-dependent". We're on our own.
Comment 16•21 years ago
|
||
This should be done with a nsIStreamListener, either directly in txStylesheetSink or in a separate object. This needs to hook itself up between the channel and the parser. This should detect all netwerk errors, including 404 and bad mime. It could provide a hook for both chrome and file schemes to trigger content sniffing, too. This would be in OnStartRequest, check for unknown-content and the right scheme, get the stream-converter-service and convert it. But that should be a separate bug, IMHO.
Comment 17•21 years ago
|
||
> It could provide a hook for both chrome and file schemes to trigger content
> sniffing, too.
That should arguably be moved down into the channel impls, a la ftp and http
channels.
Assignee | ||
Comment 18•21 years ago
|
||
Fixed with checkin for bug 203192.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•