Closed Bug 430475 Opened 14 years ago Closed 11 years ago
Feed sniffing broken for broken content-disposition headers without disposition
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.
it seems to be only the coding of that specific xml/rss here's one that works fine: http://digg.com/rss/index.xml
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"
Status: UNCONFIRMED → NEW
Depends on: 272541
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: RSS is view as text file → Feed sniffing broken for broken content-disposition headers without disposition
Version: unspecified → Trunk
Recommendation: do not attempt to work around broken headers, just ignore them consistently.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
What's the fix you want to see, philor?
Related test case: <http://greenbytes.de/tech/tc2231/#attmissingdisposition>
Furthermore, can somebody explain how failure to extract the filename from a broken Content-Disposition header field affects feed processing?
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.
Thanks for the explanation.
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.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.