• Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category User Interface
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Medium
  • Reported Version 1.0-beta
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Flyspray
Opened by microniko - 16.01.2016
Last edited by peterdd2 - 17.01.2016

FS#2097 - Url incorrect for view attachement

I’m using URL rewriting…

If I click on the link, the picture doesn’t appear.

It’s ok in task history. The right URL is


   test.jpg (7.3 KiB)
Project Manager

Do you mean the broken closebutton-image of the fancybox or viewing the attachment itself?

If you mean viewing the attachment I can't reproduce here in my install - also with url rewriting active and on a subdomain. Have you tried it with flyspray github master too?

I know there is a small bug in combination of fancybox and url rewriting. There is a pull request which simple fixes this:

but I merged it not yet to github master, because of MAYBE unwanted side effects when flyspray is integrated with other software, that doesn't like a "base href" tag in header.
(Need feedback/confidence here from others if it is ok..!)

The problem is for viewing the attachment.

I installed flyspray ~ 11th jan. I think of having downloaded the bad version, this page is not update…

I'm going to test beta2.

I tested the beta2 and the GitHub version, I have the same problem…

Project Manager

what is the output? error messages?

does it work when you disable nice urls? (/admin/prefs)

still cant reproduce the error on my install.

Without RewriteURL I see this URL in FF status bar : But the fancy box never show the attachment. (see first attachment)

And with RewriteURL, I see this URL in FF status bar : And the fancy box show me the broking file of FF… (2nd attachment).


Mmh, which browser and browser version, operating system...?

Here a screenshot of firefox43/linux with developer tools (F12) showing the loading of the attachments.

  • Do you see some errors in the js-debugger?
  • Does the problem occur only in one browser or also others? e.g check internet explorer,safari,firefox,opera..
  • Do the attachment files really exists under directory attachments/ ?
  • Are they readable by the apache server?

You can load the url you see in the statusbar as new tab too: rightclick on attachment link and select something like 'open link in new tab' from the popup context menu.

So you can see if the attachment loading is the problem or if it is a javacript problem of fancybox showing the attachment in the same browserwindow.

Hi guys,

I also have the same problem, but with Version I'm running the vanilla version on a VirtualBox with Linux Mint Debian Edition.

My file is a .PNG picture and the URL reads as follows: [...]/flyspray/index.php?getfile=2
The file itself is accessible via attachement folder, but not via browser.

I also attached a picture of the attachments folder. Could there be a problem with the file referencing?

Project Manager

What is the output of accessing /flyspray/index.php?getfile=2 ?
Error messages?
(You can use developer tools - pressing F12 should open them - in current browsers.

Here the output of the anwser HTTP header when I try /?getfile=4 (a googlemaps icon in jpg format) on one of my github master installs (uses nice urls enabled too):

HTTP/1.1 200 OK
Date: Wed, 10 Feb 2016 20:37:18 GMT
Server: Apache
X-Powered-By: PHP/5.5.30
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: public
Content-Disposition: filename="googlemaps.jpg"
content-transfer-encoding: binary
Content-Length: 2653
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Content-Type: image/jpeg; charset=binary

The file itself is stored in folder attachements/ of flyspray install, but the filenames are intentional scrambled/randomized, so unauthorized users cannot just download the file if they know the name. The normal readable name is stored in flyspray database.

Note to myself: Research meaning of http header param 'Pragma: public' (is it for caching proxies?)

The output was the same as yours. It just didn't download the whole file as if the stream was interrrupted.
Anyway I solved the problem by finally upgrading to 1.0 Beta 2 and without ticking the URl rewrite function.


Available keyboard shortcuts


Task Details

Task Editing