HTML pages served by subversion DAV module of Apache 2.0.51 are not recognized as HTML

RESOLVED INVALID

Status

()

Firefox
General
RESOLVED INVALID
13 years ago
13 years ago

People

(Reporter: Richard Musil, Assigned: Blake Ross)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041016 Firefox/0.10.1

When I try to load a HTML page from subversion server (which runs on Apache 
httpd) the page is displayed as "verbatim" HTML text (i.e. plain text with 
first line starting with <!DOCTYPE HTML PUBLIC ....). Also, just mentioning 
here that localized character in any page are rendered as "diamonds with ?", 
since the browser does not recognize the encoding (specified in meta-tag).

Reproducible: Always
Steps to Reproduce:
1. Setup subversion server using WEB_DAV on apache 2.0
2. Check in some HTML pages.
3. Browse the pages over SVN WEB_DAV access.

Actual Results:  
The page is displayed as "verbatim" HTML text (i.e. plain text with first line 
starting with <!DOCTYPE HTML PUBLIC ....). 

Expected Results:  
I would expect it to be rendered as HTML instead. At least, this is what IE do. 
I am not sure whether this is correct by standard, by this is definitely 
desired.

Comment 1

13 years ago
Look in Page Info for the page in question, and you'll probably find that the
server is sending it as text/plain.  In which case we're doing what the server
said to do.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

13 years ago
You are right, I am sorry I did not figure it out before. Sad thing is that in
this particular case I will need to stick to non-conforming IE, because I doubt,
it could be fixed on SVN or Apache.
(Reporter)

Comment 3

13 years ago
To reply to my previous reply I want to add that it does not need to be fixed
anywhere. SVN has property mime-type, which, when set to "text/html" ensures
that server sends content as such. By default it sends "text/plain" for anything
but binary.
Just in case anyone cares.
You need to log in before you can comment on or make changes to this bug.