Bug in event_galleryimage plugin: Content-Type wrong

[bpkri]

I discovered a bug in the event_galleryimage plugin:

I use this plugin in version 1.4 with gallery 2 integration. Whenever I insert a picture from my gallery in a post via the [GImage] tag, the feed is broken in some cases: The Content-Type header is set wrong.

Okay, here are the details:

when calling a feed via http://my.blog.url/feeds/atom03.xml (or /index.rss2) the Content-Type is text/html instead of text/xml
The same ofcourse is true if the feed is called via http://my.blog.url/index.php?url=/feeds/...

The feed has the correct Content-Type if is called via:
http://my.blog.url/rss.php?version=atom0.3 (or whatever other feed you want to use).

The feed also has the correct Content-Type header, if the [GImage] markup is not used.
However I already took a look at the plugin itself and this does not set the Content-Type header at all.

So we have:
- Wrong Content-Type header if [GImage] markup is used and the feed is called via index.php ( /feeds seems to do just that)
- Correct Content-Type header if [GImage] markup is not used in feed or call to feed is made via /rss.php?...

I already fixed this for my blog by editing rss.php: I moved the line that sets the Content-Type header to the very end of the code here.

[garvinhicking]

Hm, sorry but I cannot reproduce this behaviour. I just installed the plugins, and my headers show up fine!

Which other event plugins are you using? Can you give us your real URL? I'd like to inspect the HTTP headers of your page.

The gallery-image plugin only contains a single Content-Type setting. What you could do is this:

Edit your index.php, rss.php and serendipity_event_galleryimage.php files. Look for any "Content-Type" string, and then set a new header after that. So for example, in your plugin file replace this:

Code: Select all

header("Content-Type: $content_type");

with this:

Code: Select all

header("Content-Type: $content_type");
header("X-Content-Type-Source-Galleryimage: true");

Of course use a different "X-Content-Type-Source" header in each of the files, so when you replace in your index.php this:

Code: Select all

header('Content-Type: text/html; charset='. LANG_CHARSET);

with this:

Code: Select all

header('Content-Type: text/html; charset='. LANG_CHARSET);
header('X-Content-Type-Source-Index: true');

Now, with the firefox extension "LiveHTTPHeaders" you will be able to inspect the headers of your blog. You will also see which file emits the headers, and then we can further debug the problem. The content-type set method of the plugin shouldn't even be called!

Regards,
Garvin

[bpkri]

Hmm.
Okay, I'll do that tomorrow evening. But first I'll try and update my s9y installation to the latest nightly build to see if it's a problem there.

I could set up a second blog as a test-instance and hand the URL to that, but that'll have to wait a bit. The idea with the additional Content-Type headers ain't bad. Could have thought of that myself. I'll modify my installlation like this tomorrow. Maybe then we can see something

THe plugin only set Content-Types for images the way I see it.
Will try that anyways however

[garvinhicking]

Thanks for trying; just report back when you've had the time.

Regards,
Garvin

[bpkri]

Test blog is already set up

s9y was faster to install than I remembered. (which is pretty cool)

Test blog is set up:
go to http://blog.pirotesse.de

There you can see the wrong behaviour. Basically the only plugin I use besides what's already shipped with the standard is the galleryImage plugin freshly installed from Spartacus in version 1.5

Didn't fiddle with any files.

If you call:
http://blog.pirotesse.de/feeds/atom03.xml

You can already see that it's wrong without even looking at the headers.
(phew. I was afraid that additional plugins might cause problems there, but I was lucky: it the bug was very easy to reproduce.)

Next to do is modify the php files to include the additional header information.

[garvinhicking]

Great.

Say, can it be that you are using a central include on your domain pages? The headers of the atom feed set a "GALLERYSID" cookie -- but Serendipity does not provide this. So I am guessing that either via php.ini or .htaccess some other PHP files are auto-loaded before s9y takes place.

Can that be, can you please check?

Regards,
Garvin

[bpkri]

errm... How do I check this?
I wouldn't know that I use a central include on my pages, neither via php.ini, nor via .htaccess. However I think gallery provides that cookie.

Errm...
I found this in the admin page of my gallery 2, under general-> cookies:

If your Gallery is embedded and you leave the following fields empty, then all DownloadItem links (the URLs of the images and other items) in the embedded Gallery have an appended GALLERYSID string in the URL which is a minor security risk when your Gallery users start copy'n'pasting image URLs in forums, guestbooks, etc. The alternative is to set the cookie path. Gallery will then not append the GALLERYSID to the embedded DownloadItem URLs. E.g. when Gallery is reachable at http://www.example.com/application/gallery2/ and the embedding application is at http://www.example.com/application/, then you have to compare the path /application/gallery2/ with /application/. The cookie path is the part of the paths that is equal, in this case it is '/application/'. Most often it is just '/'.
The cookie domain is also only needed for embedded Gallery installs and only if you want to get rid of the GALLERYSID string in the embedded DownloadItem URLs. In most cases, the cookie domain can be left blank. Set it only, if Gallery and the embedding application are only reachable with different subdomains. E.g. when Gallery is at http://photos.example.com/ and the application is at http://www.example.com/, then you have to set the cookie domain example.com (the part of the host string that is common to both, Gallery and the embedding application).
Once you change the cookie settings, all registered users of your Gallery will have to clear their browser cookie cache. If they do not, they will experience login / logout / lost session problems.

So it would seem rather normal to me, that this cookie is set?

(by the way I just changed the configuration of gallery to include a cookie path "/" and a domain "pirotesse.de", as it was recommended...)

Also the cookie is set, too if you jsut view blog.pirotesse.de . Seems to be the way gallery behaves if called embedded.

[dma147]

really curious...

I've just tried this too on my own blog.
--> http://blog.linux-stats.org/

Without the last entry (the gallery2-test) the atom0.3 feed seems to be correct. But with this last entry, it shows up as a html page.
But the source-code of this feed seems to be absolutly correct to me...?!

[bpkri]

Yes, that's exactly the problem I mean. The sourcecode doesn't change, seemingly only the content-type header changes (which causes feedvalidator not to validate the feed 100% and MIGHT cause problems with some feed readers.)

Umm... but you have other posts with the [GImage] markup that don't cause the feed to break?

[dma147]

No, every [Gimage] breaks the feed.

But I've found the malefactor! It is really gallery2.
okay, a dirty workaround is the following:

Open "modules/core/classes/GalleryTranslator.class" from within your gallery2 installation directory and change the line 281:

From this:

Code: Select all

      header('Content-Type: text/html; charset=UTF-8');

To this:

Code: Select all

      // header('Content-Type: text/html; charset=UTF-8');

Then the header will never change anymore and either gallery2 itself and the embedding and all is still working.

I have to find a solution which prevents ofrom editing files.

[bpkri]

Heh. as I thought.

Well... nearly as dirty as my own workaround which sets the header in s9y's rss.php after everything else happened.

Need to remember this bit of information though.

[garvinhicking]

Great detective work, guys.

Sadly the problem is not easily bypassable. Actually it needs fixing in the embed.php of Gallery - this should not set a content-type header.

Sadly PHP provides no means to check whether a header has been sent already, and the galleryimage cannot just send its own Content-Type header, as the text/xml is only required for RSS feeds and the plugin may not know about this.

Regards,
Garvin

[dma147]

I'm already in discussion about this with some gallery2 developers...
Lets see, what they think about this.

[bbruecker]

I 've got the same problem with S9Y 9.0.1 and plugin version 1.5. Is ther any solution avaiable now? TX Benjamin

[garvinhicking]

Benjamin, did you read what was posted earlier in this thread? There is a workaround posted.

Regards,
Garvin