Closed Bug 353717 Opened 18 years ago Closed 14 years ago

weird behaviour with subversion repository containing xml documents with xslt stylesheets

Categories

(Firefox :: General, defect)

1.5.0.x Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: maciej.pijanka, Unassigned)

Details

(Whiteboard: [CLOSEME 5-15-2010])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

I use svn accessed by https/webdav containing xml documents (docbook to be specific), when i look at document (http live headers says text/xml which is what i set in svn:mime-type property) it show just content ommiting all formathing which should be done if xslt is used and no node names which should be visibile when no xslt is used.
So i checkouted file to directory and tried access it both via http and direct file, in both cases document is formated correctly as xslt specifies, for http it still has text/xml content type.. 
appear both on subversion 1.3.x and 1.4.x, and firefox 1.5.0.7 and something older 1.5.0.4 i think 

Reproducible: Always

Steps to Reproduce:
1. create xml document in subversion repo
2. set stylesheet at it, svn propset svn:mime-type text/xml docfile.xml ; svn ci
3. look at it via webdav
This file must have svn propset svn:mime-type text/xml to be recognized as xml when browsing otherwise text/plain is send.
After some tests i figured that plain file accessed using file access dont work too unless xsl stylesheet is available via same protocol (am not sure if i wont made mistake with that assumption..but quick test now shows its correct)
after some additional search got more clear problem
i put simple xml file at ~agaran on my box, but set xsl-stylesheet path via
href to https://, then firefox skips parseing but dont say anyting about missing stylesheet, if i switch back to http href to stylesheet it works again
on plain apache with no svn around..
looking into console shows message: content from http.. cannot load stylesheet from https because of security (not direct translation) 
but why firefox dont say anything about that? it loads images from http when main content is on https.. that was svn/xsl case at first time..
and why i cannot say i agree to risk and continue?
Same problem appear for 2.0rc1, 
its simple to replicate, put test file on http website, and xsl file on https, (even same server or localhost), firefox wont say anything and wont use xsl
put both on http or both on https, will work.
i belive this isnt feature.. 
This looks like a duplicate of:
 - #205294 or #353886 for the access problems (except here it's the XSLT document and not XML documents loaded in the XSLT document itself through the "document" function)
 - #245463 for the bad error reporting to the user
Flags: blocking1.8.1.4?
Not blocking. If there's a trunk fix we can look at the risk of back-porting into a future release.
Flags: blocking1.8.1.4? → blocking1.8.1.4-
Oops sorry, I did not intend to set the proposed-for-blocking flag.
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode
Whiteboard: [CLOSEME 5-15-2010]
Version: unspecified → 1.5.0.x Branch
No reply, INCOMPLETE. Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: