If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Page displayed as application/rss+xml even though delivered as text/plain

VERIFIED FIXED

Status

()

Firefox
RSS Discovery and Preview
VERIFIED FIXED
11 years ago
8 years ago

People

(Reporter: Martin von Gagern, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061113 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061113 Firefox/2.0

I'm developing the PHP in the URL stated above. To help me debugging I established an override to display the contents as another document type instead of application/rss+xml, the correct default. This worked before (in FF 1.5 I think it still did). But now FF thinks himself very clever and displays the page as RSS nevertheless.

First and foremost I'd like the browser to honour the Content-Type specified by the web server. It's bad enough with all those web pages relying on Internet Exploder to guess types, we don't need additional misconfigurations to go unnotoiced because Firefox becomes clever as well. And maybe the Server just meant what it said about the content type.

In case this "feature" should stay, please make it configurable! And probably display some big warning somewhere so people notice that the Web site is broken, that Firefox is being clever, and to inform them how to configure this cleverness.

Reproducible: Always

Steps to Reproduce:
Visit above URL
Actual Results:  
Page displayed as RSS, i.e. a form to subscribe and below the RSS news items.

The Page Info states application/xhtml+xml which is a third type, neither the designated nor the displayed one.

Expected Results:  
Page rendered as text/plain.

Page Info should always display Content-Type as provided by the server.
(Reporter)

Updated

11 years ago
Component: General → RSS Discovery and Preview
QA Contact: general → rss.preview

Comment 1

11 years ago
I have run into the same problem.  The problem occurs even if you set the content-disposition header value to "attachment", and set the file extension to txt.

Comment 2

11 years ago
(In reply to comment #1)
> I have run into the same problem.  The problem occurs even if you set the
> content-disposition header value to "attachment", and set the file extension to
> txt.
> 

The content-disposition bug is fixed in 2.0.0.1
Duplicate of this bug: 384010

Comment 4

10 years ago
Reproduce with Firefox-trunk/WinXP

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Version: unspecified → Trunk

Updated

10 years ago
Duplicate of this bug: 387041

Comment 6

10 years ago
Should this be invalid by fixing bug 381357?
Absolutely nothing to do with that. This is about wanting the preview page to *not* display for text/plain (which isn't going to happen, given the huge number of feeds accidentally sent as text/plain), that was about wanting live bookmarks to work for feeds sent as text/html.

Comment 8

9 years ago
WORKSFORME with Firefox/2008091303-trunk/WinXP

Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1b1pre) Gecko/20080913031911 Minefield/3.1b1pre

Fixed by Bug 394416 ?
Yep, as long as that part of it manages to stick.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Depends on: 394416
Resolution: --- → FIXED
Verified it has been fixed on build

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090530 Shiretoko/3.5pre (.NET CLR 3.5.30729)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.