weird behaviour with subversion repository containing xml documents with xslt stylesheets

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
12 years ago
9 years ago

People

(Reporter: maciej.pijanka, Unassigned)

Tracking

1.5.0.x Branch
x86
Linux
Points:
---
Bug Flags:
blocking1.8.1.4 -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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
(Reporter)

Comment 1

12 years ago
Created attachment 239640 [details]
Test file, if served from subversion produces weird behaviour if via http works.

This file must have svn propset svn:mime-type text/xml to be recognized as xml when browsing otherwise text/plain is send.
(Reporter)

Comment 2

12 years ago
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)
(Reporter)

Comment 3

12 years ago
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?
(Reporter)

Comment 4

12 years ago
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.. 

Comment 5

12 years ago
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-

Comment 7

12 years ago
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
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.