User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.30)
Build Identifier: Version 3.0
I was running with version 3.0 release candidate 1 with no problem. When I updated to version 3.0, my RSS reader failed to read the atom feed. I tried 4 other readers and had similar problems with parsing the XML. This seems like a bugzilla problem.
Steps to Reproduce:
1.Start up RSS reader client
2.Try to download headers
Received XML parse error
Should download the headers
Which readers are you using? I have no problem with the 'Sage' extension of Firefox.
Some readers I've tried:
1. RSSReader (stand alone, http://www.rssreader.com/)
3. blogbot (Outlook plugin, http://www.blogbot.com/)
4. RSSPopper (Outlook plugin, http://rsspopper.blogspot.com/2004/10/home.html)
Hope this helps...
I am running bugzilla with authentication being required. Even though the readers have the required information of userid/password as being the same I type into bugzilla, they are failing. However, if the requirement for authentication is removed, then I can use the readers with no problem so this is probably some sort of authentication issue.
I thought we have such a bug somewhere already, but I cannot find it.
If you append &Bugzilla_loginfirstname.lastname@example.org&Bugzilla_password=my_passwd to the end of the URL of the feed, you should be able to see the feeds correctly. At least this works from within Thunderbird. Does it fix the problem for you as well using the feed readers you mentioned in comment 2?
Frédéric, re: comment #5, that solution is a valid but very unsecure workaround. I'm interested to know if bugzilla uses a certain type of encryption so instead of showing your password in cleartext, I can just use a hash to encrypt my password and bugzilla would still understand it.
(In reply to Perze Ababa from comment #6)
> workaround. I'm interested to know if bugzilla uses a certain type of
> encryption so instead of showing your password in cleartext, I can just use
> a hash to encrypt my password and bugzilla would still understand it.
This isn't more secure than plain text, because someone else could reuse this hash if he can access the URL. So no, Bugzilla doesn't support this.
*** Bug 810194 has been marked as a duplicate of this bug. ***
The workaround does appear to work with wget, etc., but it still fails with Google calendar. I'm not sure why. Here's how to replicate:
1. log into bugzilla
2. perform a named/saved search
3. copy the "iCalendar" URL at the bottom of the page (i.e., <http://[dom]/issues/buglist.cgi?[...]&ctype=ics>)
4. append the workaround parameters to that URL (i.e., <http://[dom]/issues/buglist.cgi?[...]&ctype=ics>&Bugzilla_login=[user]&Bugzilla_password=[password])
5. log into Google calendar (i.e., <https://www.google.com/calendar/>)
6. go to "Other calendars" -> "Add by URL"
7. paste the URL created in step #4 into the "URL:" field and click the "Add Calendar" button
"Failed to add imported calendar at http://[dom]/issues/buglist.cgi?[...]&ctype=ics&Bugzilla_login=[user]&Bugzilla_password=[password] for [Google login]"
But, if you use the same URL from step #4 in wget, it seems to work. I *suspect* that Google may be smart enough to look for certain parameter name patterns and not want to send them in cleartext (e.g., via HTTP). I will try to verify....
FYI, I'm still getting the same error with an HTTPS URL from Google calendar.