430475 - Feed sniffing broken for broken content-disposition headers without disposition

Status: RESOLVED WONTFIX

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[Erick Fauquette]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre

message : The XML file does not appear to have any style information associated with it . The document tree is shown below.

Reproducible: Always

Steps to Reproduce:
1. http://www.s1000d.org/?sector=resources&page=feeds&feed=news
2.
3.

Comment 1

[Corey Farwell]

it seems to be only the coding of that specific xml/rss
here's one that works fine: http://digg.com/rss/index.xml

Comment 2

[Phil Ringnalda (:philor)]

It's because the site is sending a broken "content-disposition: filename=text.xml" header, and the code we copied to deal with missing dispositions in content-disposition headers doesn't actually work.

If you know anyone involved with the site, you can tell them that they can fix their problem (though doing so doesn't mean this bug is fixed) by adding "inline" to that header: it should actually be "Content-Disposition: inline; filename=text.xml"

Comment 3

[Julian Reschke]

Recommendation: do not attempt to work around broken headers, just ignore them consistently.

Comment 4

[Jason Duell]

What's the fix you want to see, philor?

Comment 5

[Julian Reschke]

Related test case: <http://greenbytes.de/tech/tc2231/#attmissingdisposition>

Comment 6

[Julian Reschke]

Furthermore, can somebody explain how failure to extract the filename from a broken Content-Disposition header field affects feed processing?

Comment 7

[Phil Ringnalda (:philor)]

Bug 272541 landed code to deal with content-disposition without a disposition.

Feed sniffing copied that code, because it needs to avoid sniffing things served as c-d: attachment, so it needs to know what the c-d is.

That code turned out to be broken. "When this happens, GetParam throws."

If bug 272541 decides that what it was fixing should not be fixed, and removes the non-working code, feed sniffing should remove its copy. If bug 272541 decides that what it was fixing should be fixed, and fixes it, feed sniffing should copy that fix.

Feed sniffing's particular problem is not whether or not it extracts the filename, its particular problem is that it tries to make sure that it is not sniffing attachment, fails to figure out whether or not it is (because "when this happens, GetParam throws"), and decides not to sniff something that it should sniff.

Comment 8

[Julian Reschke]

Thanks for the explanation.

Comment 9

[Jason Duell]

bug 589292 is centralizing the parsing/determination of inline/attachment, so feedsniffing and uriloader will be using the same codepath, so there's no need to keep separate bugs open for each codepath.

We're not actually talking (yet) about changing the existing parsing logic from bug 272541.  The issue in this bug is that we're seeing

   content-disposition: filename=text.xml

Bug 272541 handled the case where

   content-disposition: ; filename=text.xml

(Except that apparently it didn't actually fix it).

Repeat:  no logic is being changed (or failed to be kept in sync with other changes) by marking this WONTFIX.   So I'm assuming it's OK to mark it as such.  Feel free to reopen if I'm missing something.