287793 - Thunderbird cannot verify certain types of RSS feeds

Status: RESOLVED FIXED

(MailNews Core :: Feed Reader, defect)

Description

[Kirk Roberts]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

To re-create the problem, try to add this RSS feed:
http://www.littlegreenfootballs.com/weblog/weblog.rss
It just stalls on the Verify stage, I've let it run for minutes and it doesn't
work.  Using a different RSS reader this will work (specifically, FeedDemon)

Reproducible: Always

Steps to Reproduce:
1. For a Blog account, go to Manage Subscriptions
2. Click Add
3. Input the following URL:
http://www.littlegreenfootballs.com/weblog/weblog.rss
4. Click OK

Actual Results:  
The progress bar reaches 100% and then nothing happens.  No error, it basically
infinite loops...

Expected Results:  
It should have added the RSS feed like it does for millions of other sites. 
Maybe its a different version of RSS?  Check the site out

Comment 1

[Mike Cowperthwaite]

I can confirm this in with a trunk build, 1.0+0320, Win2K -- so it's not the 
same problem as bug 275153.

Comment 2

[Robert Sayre]

This feed has an invalid dc:creator element under the channel.

<dc:creator><rdf:Description><dc:title>Little Green
Footballs</dc:title></rdf:Description></dc:creator>

The contents of that element are supposed to be PCDATA. So, this feed is valid
RDF, but not a valid RSS1.0 feed. We'll need to check for this exception in
utils.js/getRDFTargetValue(). I'll have a patch shortly.

Comment 3

[Robert Sayre]

(In reply to comment #2)
> This feed has an invalid dc:creator element under the channel.

> The contents of that element are supposed to be PCDATA.

Err, that is PCDATA, but the module definition says plaint text only for now.
http://web.resource.org/rss/1.0/modules/dc/

Comment 4

[Robert Sayre]

Attachment: Catch bogus RDF in utils.js/getRDFTargetValue()

Comment 5

[Robert Sayre]

Attachment: nicer diff

Comment 6

[Scott MacGregor]

fixed. 
robert, can I interest you into figuring out why the trunk builds can't parse
this feed (1.0 could):

http://raeldor.blogspot.com/atom.xml

Comment 7

[Robert Sayre]

(In reply to comment #6)
> fixed. 
> robert, can I interest you into figuring out why the trunk builds can't parse
> this feed (1.0 could):
> 
> http://raeldor.blogspot.com/atom.xml

Surprisingly, this is kind of interesting. I'll look into it further. So far,
I've spotted a couple weird things. First, I'm getting a funny assert failure:
"OnDataAvailable implementation consumed no data: 'Error', file
c:/[pathtomozilla]/netwerk/base/src/nsInputStreamPump.cpp, link 459"

Second, Blogger is sending funky headers:

    HTTP/1.1 200 OK
    Date: Thu, 31 Mar 2005 03:14:11 GMT
    Server: Apache
    Vary: Accept-Encoding
    test: %{HOSTNAME}e
    Last-Modified: Thu, 24 Mar 2005 18:29:26 GMT
    ETag: "175d276-675c-42430706"
    Accept-Ranges: none
    Content-Length: 26460
    Keep-Alive: timeout=15, max=100
    Connection: Keep-Alive
    Content-Type: application/xml

Comment 8

[Robert Sayre]

1.0 seems to be getting the same response from the server, but not failing.

Comment 9

[Robert Sayre]

(In reply to comment #6)
> fixed. 
> robert, can I interest you into figuring out why the trunk builds can't parse
> this feed (1.0 could):
> 
> http://raeldor.blogspot.com/atom.xml

This feed contains  MSOffice "HTML" insisting that it's XHTML content. There's
an <o:p/> element ("o" is an unbound prefix) in every entry that seems to be
causing XMLHttpRequest to screw up. I guess it's streaming to the XML parser as
it's downloading. 

I verified this by hosting the feed on my own site and encountering the same
error. When I went through and removed the unbound elements, it worked fine,
though it still contained invalid bytes (smartquotes).

Comment 10

[Robert Sayre]

Attachment: report progress to the right place

just a typo I spotted

Comment 11

[Scott MacGregor]

Comment on attachment 179377 [details] [diff] [review]
report progress to the right place

I just checked this fix in. Sorry for the delay, I lost track of the change.