Community
Participate
Working Groups
I cannot reuse the bugzilla feeds in Yahoo!Pipes or Feedburner as they require a cookie authentication. A test to see if the feed is accessible is to do a wget: wget "http://bugs.eclipse.org/bugs/buglist.cgi?chfieldto=Now&classification=STP&component=org.eclipse.stp.bpmn&field-1-0-0=classification&field-1-1-0=component&field-1-2-0=product&product=SOA&query_format=advanced&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&value-1-0-0=STP&value-1-1-0=org.eclipse.stp.bpmn&value-1-2-0=SOA&title=Bug%20List:%20BPMN&ctype=atom" -O output gives this output: --02:08:48-- http://bugs.eclipse.org/bugs/buglist.cgi?chfieldto=Now&classification=STP&component=org.eclipse.stp.bpmn&field-1-0-0=classification&field-1-1-0=component&field-1-2-0=product&product=SOA&query_format=advanced&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&value-1-0-0=STP&value-1-1-0=org.eclipse.stp.bpmn&value-1-2-0=SOA&title=Bug%20List:%20BPMN&ctype=atom => `output' Resolving bugs.eclipse.org... 206.191.52.49 Connecting to bugs.eclipse.org|206.191.52.49|:80... connected. HTTP request sent, awaiting response... 302 Found Location: https://bugs.eclipse.org/bugs/buglist.cgi?chfieldto=Now&classification=STP&component=org.eclipse.stp.bpmn&field-1-0-0=classification&field-1-1-0=component&field-1-2-0=product&product=SOA&query_format=advanced&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&value-1-0-0=STP&value-1-1-0=org.eclipse.stp.bpmn&value-1-2-0=SOA&title=Bug%2520List:%2520BPMN&ctype=atom [following] --02:08:52-- https://bugs.eclipse.org/bugs/buglist.cgi?chfieldto=Now&classification=STP&component=org.eclipse.stp.bpmn&field-1-0-0=classification&field-1-1-0=component&field-1-2-0=product&product=SOA&query_format=advanced&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&value-1-0-0=STP&value-1-1-0=org.eclipse.stp.bpmn&value-1-2-0=SOA&title=Bug%2520List:%2520BPMN&ctype=atom => `output' Connecting to bugs.eclipse.org|206.191.52.49|:443... connected. ERROR: Certificate verification error for bugs.eclipse.org: unable to get local issuer certificate To connect to bugs.eclipse.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. If you do the same test, appending the argument --no-check-certificate, it works fine. Note that the http page redirects to https. Also note that the feed works well in Google Reader, I suppose they choose to ignore the SSL certificate. So is there a workaround to this problem ? Is it fixable ?
The reason you're getting an error with wget is that our certificate issuer (DigiCert) is not recognized by your version of wget, whereas Firefox, IE, Google and most other browsers do recognize the issuer (In firefox, preferences > advanced > encryption > view certificates > authorities > digicert, inc). Google can't just ignore an SSL-encrypted transmission :-) With that in mind, you *can* access the feed with wget without needing an authentication cookie. The cookie is only required for creating and updating bugs. So at this point, why don't the feeds work with Tahoo or Feedburner? What's the error message?
On Feedburner as well as on Y!Pipes, the error is pretty obscure. At first I thought that was because of the URL (900 characters long), and I used tinyurl to work around that. But it still would not work. To reproduce, sign in to Feedburner, it's free, and then enter the bugzilla URL feed in the field to add a new URL. I also tried to use the bugzilla feed in a wordpress widget to have it appear on the bpmn modeler blog, and it showed an error there as well. I tried the URL in the feed validator recommended by feedburner which points at some problems, maybe they actually are the problem, check it out: http://feedvalidator.org/check.cgi?url=http%3a%2f%2fbugs.eclipse.org%2fbugs%2fbuglist.cgi%3fchfieldto%3dNow%26classification%3dSTP%26component%3dorg.eclipse.stp.bpmn%26field-1-0-0%3dclassification%26field-1-1-0%3dcomponent%26field-1-2-0%3dproduct%26product%3dSOA%26query_format%3dadvanced%26type-1-0-0%3danyexact%26type-1-1-0%3danyexact%26type-1-2-0%3danyexact%26value-1-0-0%3dSTP%26value-1-1-0%3dorg.eclipse.stp.bpmn%26value-1-2-0%3dSOA%26title%3dBug%2520List%3a%2520BPMN%26ctype%3datom
Any news on this ? Should this be forwarded to the bugzilla team ?
(In reply to comment #3) > Should this be forwarded to the bugzilla team ? Well, I guess it would be better to forward it to the Feedburner and Yahoo team. The feed works fine in Firefox and RSSOwl. Especially the problems mentioned on feedvalidator.org aren't reproducible either. I guess this tool has some character encoding issues. It was built by humans too so I wouldn't rely on it as *the* source for feed validation.
(In reply to comment #4) > (In reply to comment #3) > > Should this be forwarded to the bugzilla team ? > > Well, I guess it would be better to forward it to the Feedburner and Yahoo > team. The feed works fine in Firefox and RSSOwl. Especially the problems > mentioned on feedvalidator.org aren't reproducible either. I guess this tool > has some character encoding issues. It was built by humans too so I wouldn't > rely on it as *the* source for feed validation. > I'll contact the Feedburner team, see who gets what wrong.
I posted a message on the feedvalidator mailing list: http://groups.google.com/group/feedvalidator-users/browse_thread/thread/f42bfc8265d7f9fc
And as I replied there, you really only have one choice, run contrib/recode.pl to convert your Bugzilla's data from "a random collection of whatever encodings browsers happened to send" to UTF-8, and then set the utf8 param so Bugzilla will actually send UTF-8 and say that it's sending UTF-8, rather than the current situation where it doesn't say anything, and the XML spec says that means you are sending UTF-8, even though the ISO-8859-1 you are sending is broken UTF-8. I asked justdave, who was the one to run recode.pl on bugzilla.mozilla.org, and he said it was painless other than needing to take a two hour downtime (I don't remember exactly when that was, but probably between 300K and 400K bugs). Oh, and I disagree that it works with Firefox as-is. There might be ways to set charset detection (or non-detection just defaulting to ISO-8859-1) so that the preview works, but for me with autodetection on, Firefox doesn't admit that the XML had a fatal error, but it displays the last character in Antoine's surname as a question mark in a diamond. Internet Explorer does the right thing, and throws up its hands at such busted XML.
> run contrib/recode.pl This bug then becomes a dupe of bug 220717 (or at the very least, it depends on it).
*** This bug has been marked as a duplicate of bug 220717 ***
