Hi,
I'm testing currently the rc 0.8 beta on nginx and I got issues when I try to preview or download images, doc, docx, etc files. The only ones which appear to work are pdfs, txt and files based on xml like svg.
When I download the attachment with e.g. thunderbird everything is ok, so is it a bug in rc 0.8 beta because it is working with roundcube 0.7.2.
I able to download attachments fine in RoundCube 0.8-rc on an Apache server.
i can provide a test account if you like.
I don't think that would help very much. Since it works on an full Apache system its obviously a bug thats more platform specific. Out of curiosity are you using Nginx as a passthrough to Apache or are you using PHP-FPM?
My configuration on the server is.
nginx 1.2.0-1~dotdeb.1
php5-fpm 5.3.13-1~dotdeb.0
Pages are served with php5-fpm and nginx. No passthrough.
EDIT:
It appears that the rc 0.7.2 version is outputting the file as dos\windows ansi and the rc0.8 beta as dos\windows utf-8.
When I convert now the rc 0.8 beta version with notepad++ to utf-8 without bom it works.
tested on an jpg.
So I'm guessing something changed with attachment encoding from 0.7.2 -> 0.8 beta because as I said, version 0.7.2 is
working.
Hi,
i have the same issue.
My Configuration is:
Apache/2.2.16 (Debian) Server
PHP 5.3.3-7+squeeze9
Roundcube Webmail 0.9-svn [SVN r6144]
If i click on the attached picture i get the following message:
The image "https://******/?_task=mail&_action=get&_mbox=INBOX&_uid=9425&_part=2" cannot be displayed because it contains errors."
If i right click on the attachment and choose save link as, i can download the image, but it is broken and cannot be displayed.
Any news on it? I mean obviously I'm not the only one and it is also not only nginx also apache
I setup a fresh box running the following:
- Debian GNU/Linux 6.0.5 (squeeze)
- nginx 1.2.1-1~dotdeb.0
- php5-fpm 5.3.13-1~dotdeb.0
- RoundCube 0.8-RC
I tested RoundCube with a .jpg, .pdf, .doc, .docx and they all worked fine, I also tested a very similar setup on CentOS which also worked fine. I'm not sure what else I could change to reproduce the problem.
well that means that there is still a bug.
This is the response header of roundcube itself.
Quote
Cache-Control private, no-cache, must-revalidate, post-check=0, pre-check=0
Connection keep-alive
Content-Type text/plain; charset=UTF-8
Date Fri, 15 Jun 2012 10:01:22 GMT
Expires Fri, 15 Jun 2012 10:01:22 GMT
Last-Modified Fri, 15 Jun 2012 10:01:22 GMT
Pragma no-cache
Server nginx/1.2.1
Transfer-Encoding chunked
X-Powered-By PHP/5.3.13-1~dotdeb.0
x-dns-prefetch-control off
This for example for a png called RankAPic-Logo.png
Quote
Cache-Control:private, no-cache, must-revalidate, post-check=0, pre-check=0
Connection:keep-alive
Content-Disposition:attachment; filename="RankAPic-Logo.png"
Content-Type:application/octet-stream
Date:Fri, 15 Jun 2012 10:03:20 GMT
Expires:Fri, 15 Jun 2012 10:03:20 GMT
Last-Modified:Fri, 15 Jun 2012 10:03:20 GMT
Pragma:no-cache
Server:nginx/1.2.1
Transfer-Encoding:chunked
X-Powered-By:PHP/5.3.13-1~dotdeb.0
x-dns-prefetch-control:off
What happens if you switch roundcube attachment download/preview from utf-8 to utf-8 without bom?
Because as I mentioned it does work after I download the files and convert them.
The headers are the same as the one on my system, what do you mean by:
Quote from: horfic on June 15, 2012, 06:07:31 AM
What happens if you switch roundcube attachment download/preview from utf-8 to utf-8 without bom?
Well, as I stated in a previous post
QuoteIt appears that the rc 0.7.2 version is outputting the file as dos\windows ansi and the rc0.8 beta as dos\windows utf-8.
When I convert now the downloaded attachment from rc 0.8 beta version with notepad++ to utf-8 without bom, it works.
tested on an jpg.
So I'm guessing something changed with attachment encoding from 0.7.2 -> 0.8 beta because as I said, version 0.7.2 is
working.
BOM = Byte order mark
I'm still not 100% sure what you mean, the file is downloading as a ANSI if I convert it to UTF-8 without BOM it breaks.
In RC 0.7.x, the attachments getting downloaded as ansi encoded file.
In RC 0.8.x the attachments getting downloaded as utf-8 encoded file.
This utf-8 encoded file is corrupted and if I'm converting the downloaded file from utf-8 to utf-8 without bom the file works fine.
Now?
Not sure in my RoundCube 0.8-RC install the attachment file was downloading as ANSI. Maybe its a problem tied to the mail server or actual attachment file.
I don't think thats a problem with my mailserver or the attachments!
All attachments work under thunderbird, outlook, roundcube 0.7.x, mac mail, etc. works all.
Just not rc 0.8.
I'm not disagreeing with you that its not mailserver or the attachments but it could be something in one of them that is causing RoundCube to break. I'm just trying to rule out the other major parts of the platform since it doesn't seem to be related to nginx or php5-fpm.
have you checked that none of the rc files have a BOM at the top? I mean things like the config files or any localisation ones if you have edited any? AFAIK no files in rc should have a BOM and if you look at older posts in the forum you'll see that this issue has occured when they have been added by accident.