Content-Type for Atom-Feeds

[Boris]

According to the RFC 4287, Atom-Feeds should be delivered as "application/atom+xml", which is currently not happening. (At least in 0.9, and the current SVN does not look as if it was included).

If there are no reasons speaking against this, it would be nice to follow the RFC.

EDIT: In this case it should be updated in feed_*.tpl too.

[garvinhicking]

One problem of sending that mimetype still is that it will then no longer be rendered within the Browser, but offered as a file download.

I don't think this is a cool thing, because currently Atom Feeds can be rendered within the browser with XSL stylesheets.

Try it:

Code: Select all

Index: rss.php
===================================================================
--- rss.php     (revision 860)
+++ rss.php     (working copy)
@@ -184,6 +184,7 @@
         break;

     case 'atom1.0':
+        header('Content-Type: application/atom+xml; charset=utf8');
         $namespace_hook = 'frontend_display:atom-1.0:namespace';
         break;
 }

Regards,
Garvin

[Boris]

One problem of sending that mimetype still is that it will then no longer be rendered within the Browser, but offered as a file download.

I don't think this is a cool thing, because currently Atom Feeds can be rendered within the browser with XSL stylesheets.

I see, for the majority it'll be better to stick with text/xml. As far as I understand the RFC it's not a must.

Anyway, I think "application/x.atom+xml" shoud be updated in feed_atom1.0.tpl.


Just another Note: <email></email> is no MUST-have in Atom1.0:

Person constructs MAY contain an atom:email element, but MUST NOT contain more than one.

Perhaps there is a way to keep nospam@example.com out of the Atom1.0 feed. I don't know if it is possible with Smarty (would require a string-compare).

Personally I removed it from my .tpl (smartyable Feeds are a very cool feature BTW)

[judebert]

Smarty can string compare (use eq or ==, ne or neq or !=). You can also use or and and for boolean conditions.

You should be able to

Code: Select all

{if $email != "nospam@example.com"}<email>$email</email>{/if}

Or whatever $email is in the RSS templates. (Disclaimer: I haven't tried that yet, I'm still getting accustomed to this RSS stuff.)

[garvinhicking]

Hi Boris!

Anyway, I think "application/x.atom+xml" shoud be updated in feed_atom1.0.tpl.

Do you happen to have a RFC/Spec where it says that? Before I change that, I would like to read about it, just be sure that I don't break anything. I believe you are right, but double-checking is never bad

Best regards,
Garvin

[Boris]

Do you happen to have a RFC/Spec where it says that? Before I change that, I would like to read about it, just be sure that I don't break anything.

Of course, here you are:

Both kinds of Atom Documents are specified in terms of the XML
Information Set, serialized as XML 1.0 [W3C.REC-xml-20040204] and
identified with the "application/atom+xml" media type.

And as a second source, see the IANA-List of MIME-Types.

I believe you are right, but double-checking is never bad

Vertrauen ist gut, Kontrolle ist besser

[garvinhicking]

Hi Boris!

Thanks for that pointer. I just committed the change!

Best regards
Garvin

[Boris]

Thanks for that pointer. I just committed the change!

No problem, I have to thank you

[Boris]

Code: Select all

+        header('Content-Type: application/atom+xml; charset=utf8');

It has been over a year since my best friend Lilly... Sorry wrong tape... ;-)
It has been over a year since I requested this, but now I discovered a really minor glitch in this patch.

Die Zeichenkodierung im HTTP-Header (UTF8) weicht von der Zeichenkodierung der XML-Deklaration UTF-8 ab.

(English: The HTTP-Header-Encoding (UTF8) differs from the XML-declaration (UTF-8))

I don't think this has any pratical malfunction or something like this, but it's just one missing byte, which hopefully won't hurt...

Code: Select all

+        header('Content-Type: application/atom+xml; charset=utf-8');

While I'm at thise little validator-bugs. I don't know if s9y is generally affected by this, but my installation (custom theme and plugins) was:
http://www.validome.org/forum/viewtopicp-552-1.htm

Code: Select all

header('Content-Script-Type: text/javascript');

[garvinhicking]

Hi!

Hm, in the current rss.php that header() call is not enabled. Once I enable it, my firefox won't show the Atom feed inside the browser anymore...?! Is application/atom+xml really the content-type that should be enforced if current browsers don'T really deal with it?

While I'm at thise little validator-bugs. I don't know if s9y is generally affected by this, but my installation (custom theme and plugins) was:
http://www.validome.org/forum/viewtopicp-552-1.htm

Code: Select all

header('Content-Script-Type: text/javascript');

Actually s9y should always use <script type="text/javascript"> for each <script> container.

HTH,
Garvin

[Boris]

Hm, in the current rss.php that header() call is not enabled.

I know and I think it's better to keep it as an option for a while.

Once I enable it, my firefox won't show the Atom feed inside the browser anymore...?! Is application/atom+xml really the content-type that should be enforced if current browsers don'T really deal with it?

My Firefox deals with it.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20060601 Firefox/2.0.0.1 (Ubuntu-edgy)

I'll enforce it for Atom 1.0, but as said before I think it should not be default.

Actually s9y should always use <script type="text/javascript"> for each <script> container.

Great. This was just a proposal in case it isn't done that way.

[garvinhicking]

Hi!

My Firefox deals with it.

ah, okay. I'm still using 1.5, so that might be a difference.

Best regards,
Garvin