summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorhttp://smcv.pseudorandom.co.uk/ <http://smcv.pseudorandom.co.uk/@web>2009-02-03 14:52:26 -0500
committerJoey Hess <joey@kitenet.net>2009-02-03 14:52:26 -0500
commitaba2d83cc6c0273c30ae109b32c2ea404488116e (patch)
treea32e956e28050e15f391154975e2b09566640e0d
parented922c8e4f7e331d954eca1be812f6fe1dd3c3f2 (diff)
Report XML::Feed bug and provide a workaround for IkiWiki; please review
-rw-r--r--doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn22
1 files changed, 22 insertions, 0 deletions
diff --git a/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn
new file mode 100644
index 000000000..c2d9e17ef
--- /dev/null
+++ b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn
@@ -0,0 +1,22 @@
+The Atom feed from <http://planet.collabora.co.uk/>
+get "double-encoded" (UTF-8 is decoded as Latin-1 and re-encoded as
+UTF-8) when aggregated with IkiWiki on Debian unstable. The RSS 1.0
+and RSS 2.0 feeds from the same Planet are fine. All three files
+are in fact correct UTF-8, but IkiWiki mis-parses the Atom.
+
+This turns out to be a bug in XML::Feed, or (depending on your point
+of view) XML::Feed failing to work around a design flaw in XML::Atom.
+When parsing RSS it returns Unicode strings, but when parsing Atom
+it delegates to XML::Atom's behaviour, which by default is to strip
+the UTF8 flag from strings that it outputs; as a result, they're
+interpreted by IkiWiki as byte sequences corresponding to the UTF-8
+encoding. IkiWiki then treats these as if they were Latin-1 and
+encodes them into UTF-8 for output.
+
+I've filed a bug against XML::Feed on CPAN requesting that it sets
+the right magical variable to change this behaviour. IkiWiki can
+also apply the same workaround (and doing so should be harmless even
+when XML::Feed is fixed); please consider merging my 'atom' branch,
+which does so. --[[smcv]]
+
+[[!tag patch]]